Microsoft’s Architecture Journal 15

The latest issue of the Microsoft’s Architecture Journal is bound to rekindle the topic of maturity and purpose of the software / enterprise / technical / infrastructure / data architecture discipline. The issue is fresh off the press. Microsoft is correctly anticipating the onslaught of responses by setting up a special discussion forum. As of writing of this post the forum is not yet active, but once it becomes active the phrase tra-ta-ta-ta-ta will take on a whole new meaning.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Microsoft's Architecture MVP Changes

In late February of 2008 Microsoft dissolved the Microsoft Architecture MVP award as part of realignment of the MVP program to be more product oriented. Dissolved is a wrong word … so read on. This came as a surprise to many award recipients - including myself – who lost a “nice to have” title. This development, however, had a very positive impact on the Architecture MVP community, because it forced the architects ask themselves some hard questions about their role in the community and the role Microsoft plays in the software architecture discipline.

This post features some highlights from the ferociously bubbling listserv.

At first there was confusion. Participants understood the reasoning behind moving towards a product oriented approach, but they couldn’t fathom the disappearance of the architecture competency. Then there was anger – well summarized by one of the participants: “I believe the shutdown of the MVP Architect program is just one more piece of evidence that … Microsoft does not appreciate the role of the architect in driving large buy decisions.”

Then a word of wisdom came from Simon Guest. In order for the MVP program to grow the structure has to change. MVPs will be aligned to a product, but will be able to select a discipline such as architecture. Simon then called for an open forum at the MVP summit in Redmond on April 15^th.

Identity crisis started to emerge – some participants, including Martin Fowler, voiced their reserved opinions about the value of the MVP award. Valid questions arose – why do architects communicate so little with each other? What role do architects play in organizations? What do they do for Microsoft? The consensus was clear – although there is a clear need for robust architecture communities the MVP award infrastructure didn’t make individual architects feel part of a single unit.

Finally discussion merged onto taking proactive steps to define the scope and purpose of the group. Familiar questions arose: how do we define different types of architects? What are the definitions of architecture and architect? Should we just take some definitions from IASA? Microsoft has established a work space where the discussion of these various topics will commence.

There are no clear answers, but there are good questions – Microsoft is moving in the right direction albeit at its own pace.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Advice for apprentice software architects

The software architecture discipline has matured to the point where the core tool bag for architecture analysis and design can be learned by any serious software engineer. But this doesn’t mean that architect’s experience is no longer an important attribute of architect’s character.

The best way to learn is by doing. To quote Lakota Indian saying: "Tell me, and I'll listen. Show me, and I'll understand. Involve me, and I'll learn." Apprentice architects must seek out opportunities to work on architecturally significant aspects of various projects. Diversity here means working on projects with different SDLCs, projects of different scope and size, and projects across different functional domains. Diverse experience – preferably across different organizations – will enable an apprentice architect make better decisions in the future as the repertoire of skills and knowledge grows.

Everybody wants an architect with 10 years of experience, but nobody wants an architect with 1 year of experience ten times.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Criteria For Failure

Every project team asks themselves, implicitly or explicitly, what are our criteria for success? Depending on the range of the stakeholders involved you’ll get answers from the superficial (e.g. “users of all skill level can use software”) to the goal oriented (e.g. “identify the safest and most viable customers who need car insurance”). It’s easy to talk about success – especially non-quantifiable success.

The Firebrand Architect philosophy encourages you take a step further and pose a question: “What are our criteria for failure?” In other words – when we look back a year from now how would we know for sure we have failed to achieve our objective? Depending on your relationship with the group of the stakeholders you may have to be diplomatic as to how you pose the question.

Let’s work through an example. A project aims at providing insight into the inventory stored in many warehouses. The goal is to keep the inventory as low as possible while providing quick response to product demand. This project has a budget of $2,000,000 and will require a purchase of expensive COTS software ($500,000). A team of stakeholders will let the technical team decide which of the vendors to select, but know that a mature COTS software package has solved a similar problem in other organizations.

A year goes by, hardware has been purchased, COTS software installed and linked to a data warehouse, insight for a few categories of inventory can be obtained. Is this project a success or a failure?

One may say that since the software has been installed and connected to a data source in the production environment it’s a success. If that’s the only claim to fame, then this project is a failure. It doesn’t produce the insight that a business needs.

Using the same example as above, if a project produces some level of insight, but not all what was envisioned was it a failure or success? This is a harder question. If the paradigm and the model of operation through which the limited insight has been developed can be naturally expanded to gain insight in all envisioned categories, then the project is a success despite not delivering everything what was planned. If the paradigm doesn’t scale to cover additional level of insight, then the project is a failure.

Knowing the definition of success is important. Knowing the definition of failure is paramount.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Responsible Software Architecture

SoftwareArchitectures.com is propelling the concept of responsible software architecture. This concept is based on philosophy that every decision made by a software architect must be conscious and must be supported by a judicious decision making process that clearly demonstrates why the chosen design alternative was selected out of a range of other possibilities.

Every decision made by a software architect is made in some context at some snapshot of time. The context is defined through architect’s understanding of personal capabilities, requirements, constraints, financial resources, time, capability of the team, etc. The context changes over time, so it’s imperative to document the background against which a decision was made. When someone questions a design decision or suggests a better solution an architect must provide a scientific justification of his or her decision – without it architect’s credibility and the credibility of the solution may be compromised.

The concept of responsible software architecture is very powerful, but few architects live by it. Think about two or three most recent software architecture design documents that you reviewed. How many documents clearly explain the way key architectural decisions meet business drivers and why selected architectural approach is better than listed alternatives? Not every decision needs to be documented with an elaborative set of alternatives, but all key decisions need to be explained. Key decisions are architecturally significant choices that if changed have a profound impact on multiple quality attributes of a system.

A responsible software architect must sincerely believe that a business problem, and not technology, drives the solution. Technology may be the core vehicle for delivering the solution, but it’s not the driver – this is a paramount concept. Because technology is not the driver a responsible architect must be able to initially reason about a solution without technology specific terminology. The point here is that selection of a technology (platform, development tools, COTS software, etc.) is an architecturally significant decision that constraints the solution. An architect must be able to provide a judicious explanation as to why selected technology was chosen. Once that decision was made it’s only natural to think within the context of selected technology.

Some software architects have too much vested interest in a given technology so they only design solutions with that framework in mind. This clearly limits the range of solution alternatives, but it’s not as limiting as reusing the same architectural approach from project to project without justifying the reason for doing so. For example an architect who designed web based applications using MVC architectural style for the past four years may be inclined to use it on the next project even if a Front Controller style or an AJAX based pattern may be more appropriate. Similarly if an architect is used to a working with a process intense SDLC he or she may push for it without realizing that a new project requires agile JAD/RAD approach due to its research and development nature. The latter examples demonstrate the proverb: “When all you have is a hammer, then everything looks like a nail.” For an architect to be responsible he or she must question their decisions and make sure that appropriate audience is able to understand the reasoning behind the decisions.

SoftwareArchitectures.com is currently establishing a Center for Responsible Software Architecture. Join the discussion on responsible software architecture in a specially created forum. Each post will earn you a chance to win Evaluating Software Architectures: Methods and Case Studies book (through October 15 2007). Registration required to view and post.

Firebrand on duty: Constantin K.
www.SoftwareArchitectures.com

Question assumptions or live with consequences

Don’t assume that the knowledge you have or recently acquired is possessed by your stakeholders, customers, and clients. Even non-architectural knowledge, such as existence of alternate SDLCs, may not be known by those around you. This is a big deal, because a project may be moving forward, on a wrong orbit, while all key stakeholders assume that it’s the only way.

As an architect it’s your responsibility to challenge the assumptions and expect a reasonable explanation. The same way you, as an architect, expect to be questioned about the tradeoff decisions and alternative designs.

Firebrand on duty: Constantin K.

Asking for help - a mature decision

A software architect is in charge of the overall technical solution – there is no question about that. But a good software architect also knows his limits and requests assistance from subject matter experts on the issues outside of his or her knowledge base. Technical skills are only 49% of software architect’s skill set.

For example, a software architect with experience in web portal development is assigned to lead a project for a web based case management system. If similar technology and the same web based paradigm are used on the new project this is a reasonable request on behalf of the business management.

After studying case system requirements and after examining the quality attributes an architect sees that the system will require a highly sophisticated authorization system in order to ensure that the right users get access to the right parts of a case at the right time. If complex resource authorization is not architect’s technical strength, then a subject matter expert must be brought on board for consultation. This is not an insult to architect’s competency or ability to perform her job; it’s a mature decision that will improve the odds of designing the right functionality that serves users’ needs.

There are cases when financial constraints prohibit acquisition of external subject matter experts. Then it’s up to architect to make the best of the situation, but such decision should be documented as risk. It’s a well known fact that it’s not possible to retrofit security into a system without breaking system architecture.

Firebrand Architect on duty: CK

Duties of a Software & Solution Architect

What does it mean to be a software architect? How about a solution architect? There are as many opinions as definitions of software architecture. It is clear that a software architect is not simply a senior software engineer. Responsibilities of a software architect cover a wide array of skills outside of technical field of knowledge. The listing below is a series of opinion pieces by various bloggers and web sites on the definition of a software and solution architects.

• An Overly Long Guide to Being A Software Architect David Ing
• What does the Solutions Architect career path look like? Mark Baciak
• Anatomy of a Software Development Role: Solution Architect Robert Bogue (developer.com)
• Responsibilities of a Software Architect SoftwareArchitectures.com
• What are the Duties, Skills, etc. of a Chief Software Architect? (previous page) SEI
• WWISA view WWISA

Additional sources will be added to this post in the near future, including Microsoft’s definition. This is only a start. Add your definition or reference source.

- Firebrand Architect on duty: CK