MSDN "Skyscrapr" Video: What Architects Do

This entertaining video from Microsoft has made the rounds, but it still cracks me up. It highlights and differentiates the roles and responsibilities of Enterprise, Software/Solution, and Infrastructure Architects in an amusing and lighthearted manner. One way or another, it'll make you smile - or grimace. Check it out and enjoy.

Here are a couple of my favorite lines.

"Your building does not fit here, sir. Just have a look around."



"Sir, the system is failing because of poor planning. We need Architects! What I need is a system that supports my business."

The Proactive Architect

Focusing on the importance of being proactive, this post is subtitled "There's No Crying in Software Architecture," adapting Tom Hank's great line, "There's no Crying in Baseball," from the 1992 film A League of Their Own (view clip).

To contribute in the most significant and effective ways, the Software Architect must relentlessly pursue proactive activities that influence good decision-making at all levels of the organization. They must aggressively maintain awareness of and focus on the many dimensions associated with the realization of the Business and IT Strategy and the delivery of supporting projects.

I've written about proactive opportunities before in Architect As Advocate of the Business and The Architect is Accountable! and thought we'd expound on the topic today with specific consideration of what it means to be proactive. First, let's review the definition of the word "proactive," which Barron's Dictionary of Business Terms defines like this:

"Having an orientation to the future, anticipating problems and taking affirmative steps to deal positively with them rather than reacting after a situation has already occurred."

This definition seems to capture a couple of very important characteristics and responsibilities of the Software Architect: 1) orientation to the future, and 2) affirmative and positive action.

Building upon that definition, let's consider the perspective expressed in The 7 Habits of Highly Effective People. In this influential book, Stephen Covey identifies the quality of being proactive as the foundation of a framework of effectiveness. We can detect his view of proactivity in the following quote:

“We are responsible for our own lives... our behavior is a function of our decisions, not our conditions.” (Stephen Covey, 1990)

Of course, Mr. Covey didn't happen upon a new concept in this book. It turns out that nearly 100 years earlier, George Bernard Shaw had something similar to say on the topic:

"People are always blaming their circumstances for what they are. I don't believe in circumstances. The people who get on in this world are the people who get up and look for the circumstances they want, and, if they can't find them, make them." (George Bernard Shaw, 1893)

An essential premise can be distilled from these quotes, establishing a clear contrast between a proactive and a reactive frame of mind.

Proactive: We have the opportunity and responsibility to make choices that influence our circumstances and lead to results
Reactive: We are at the mercy of our circumstances

Stitching it all together, we can begin to see that a proactive Software Architect will leverage direct and indirect influence as appropriate to execute deliberate and positive steps that ensure today's activities and decisions are in support of the future orientation, applying positive energy that magnifies and enlarges influence and effectiveness.

To illustrate, let's consider a few examples.

Business Strategy and Roadmap

Proactive: Recognize how evolving business needs such as a market shift or even a new strategic client might be leveraged to create new opportunity for the business. Develop visibility to the opportunity and help develop the business case.

Reactive: Wait for the business to come up with an opportunity and apply energy only to those ideas they bring forth.

Performance and Scalability Assessment

Proactive: Contract with a third-party performance testing center (e.g., the IBM center in Waltham, MA) to validate product performance and scalability. Work with the test engineers to define and execute an appropriate test environment and suite of tests that take into account the full scope of the product's capabilities, architecture, anticipated volumes, etc.

Reactive: Turn the product over to an agency to do the testing, treating that agency like a "black box".

Cost Reduction

Proactive: Determine the operational cost of existing platforms and balance against business needs and expectations. Develop a strategy for refactoring, consolidation, and replacement as appropriate.

Reactive: Allow 100% of your energy to be applied to the development of new products and features, ignoring the mounting debt of inefficient capabilities and decaying architecture.

Multi-Project Synergy

Proactive: Maintain a holistic view of the enterprise, recognizing potential duplication in effort, competing needs, opportunities for common frameworks and infrastructure, etc.

Reactive: In the name of "efficiency", operate multiple independent project teams with no awareness of similarities or opportunities to cooperate with other initiatives.

To close, let's go back to the subtitle, "There's No Crying in Software Architecture." As architects, we sign up for intense accountability for results - business results. It's our job to be proactive and help navigate occasionally murky waters. In this role, we must be sure not to deflect responsibility. When things aren't going right, we're to assume responsibility and help find the way to dry land.

IASA Architect Skills Library

I was reminded today of the usefulness of the IT Architect Skills Library published by the International Association of Software Architecture (IASA). The Skills Library is an exhaustive, community-controlled collection of articles illuminating each primary skill of the Architect. From the IASA site:

"The current skills library consists of 633 pages of valuable information written by practicing architects from around the world. The skills project was commissioned by Microsoft and designed and executed by IASA for the professional community. This library will remain free to architects and it provides the first ever practical description of what IT architects do and how they do it."

The Skills Library is organized around the IASA's skills model. As illustrated below, this model consists of five "Foundation Skills" that make up the foundational body of knowledge. Built upon that foundation are specializations such as Software Architecture and Infrastructure Architecture.



Given the skills model framework, the library is organized into the following categories:

• The IT Environment
• Business Technology Strategy
• Design
• Human Dynamics
• Quality Attributes
• Software Architecture
• Infrastructure

Be sure to check out this valuable resource - one more great way to learn from the experience of others.

Good Architecture Descriptions are Explosive

Good architecture descriptions are explosive! Like C4, the architecture description can shake things up, remove roadblocks, and create opportunities where none existed before. In order to have this impact, the architecture description - the Software Architecture Document (SAD) - must be Correct, Clear, Concise, and Comprehensive. It must be C4!

As we touched on in "What is Software Architecture?," it's essential that the architecture of a software-intensive system be appropriately documented and communicated. In "The Most Important Competencies of the Software Architect," we discovered that communication is one of the most important skill groups for the Software Architect and identified the following communications competencies:

• Understand stakeholder needs
• Ensure the stakeholders understand the capabilities and limitations of the architecture
• Gain consensus on approach through diplomacy, compromise, and mediation

A quick look at the communication competencies immediately suggests the pivotal role of the Software Architecture Document (SAD). An effective SAD is essential in gathering consensus and ensuring universal understanding among the community of stakeholders.

Of course, at its core, the SAD is an assembly of models, each representing key dimensions of the architecture. These models are necessarily abstractions of the actual software system, and serve to encourage breadth of understanding, establishing context and meaningfulness to the many stakeholders. As abstractions, though, the models are somewhat removed from reality. In his book on Analysis Patterns, Martin Fowler addresses this concept in a claim that "Models are not right or wrong, they are more or less useful." The authors of Software Systems Architecture expound on the idea and argue convincingly that "Every architectural model is an approximation of reality. In other words, it is only partially accurate and partially complete."

Given the nature of the SAD as a series of abstractions, it can sometimes be a challenge to decide what content is appropriately included in the Software Architecture Document and what is better left for other (important but separate) artifacts. To help encourage good decisions in this area, it can be helpful to pursue an "Explosive" architecture description that maximizes the four C's:

• Correct - Accurate content describing the right architecture
• Clear - Easily understood and meaningful to the stakeholders
• Concise - Includes only the architecturally significant content
• Comprehensive - Addresses the true breadth of architectural concerns

Correct

Arguably "Correctness" is the foremost quality of a Software Architecture Document. The SAD is one of the most critical tools for ensuring consensus among the stakeholders. By accurately representing the needs and concerns of the stakeholders and mapping those concerns into the solution space, the Software Architect is able to validate consistent understanding of the needs and ensure they're accurately satisfied by the architecture.

To gain full benefit of the architecture description, the SAD must be kept up to date. This ensures that the right inputs are being considered and encourages good decision making. Keeping the SAD up to date requires the integration of effective processes into development, operational, and support plans.

Clear

In order to be effective as a communication vehicle, the SAD must be written in clear and straightforward language and organized/structured in a manner that promotes the ability of each stakeholder to understand the relevant parts. To accomplish this goal, the Software Architect must demonstrate two things to each stakeholder (or stakeholder group): 1) The needs of that stakeholder are accurately understood, and 2) The needs are met by the architecture. As different stakeholders have different interests, it's essential to structure the SAD in a way that accommodates the various perspectives. A common approach to dealing with this factor is the use of multiple views such as described in "The 4+1 View Model of Software Architecture" promoted by the Rational Unified Process and Phillipe Krutchen (http://www.win.tue.nl/~mchaudro/sa2004/Kruchten4+1.pdf).

In addition to multiple views and perspectives, a SAD is typically more clear when you go out of your way to establish business and technical context and to tailor the content, language, and detail to the audience's skills and experience.

Concise

Of all the SAD quality attributes, "conciseness" is one of the most difficult to achieve. But it's also one of the most important. In fact, a SAD that comes up short in conciseness is likely to come up short in other dimensions such as correctness and clarity. By carefully calibrating the level of detail represented in the SAD, the Software Architect fine-tunes the clarity of the document and makes it more meaningful to the stakeholders. Essentially, this is an exercise in maximizing the purity of the architecture description, aggressively fending off the fluff and maximizing the signal-to-noise ratio.

When the SAD is effectively concise, it represents only those characteristics of the system that are truly architecturally significant. This means, as we progress more deeply into a software project, the SAD becomes more and more stable (as the architecture becomes stable) and the document is easier to keep current. This reduces the effort associated with the maintaining the document and maximizes its value, both during the project and throughout the life of the product.

Comprehensive

Comprehensiveness can be the opposite of conciseness, so we see here one of the many balancing acts played by the Software Architect. To be effective, the SAD must include the full scope of business and technical concerns and establish a clear context for their understanding and evaluation. These concerns must then be analyzed and addressed with sufficient precision and detail to encourage strong stakeholder review and support the ongoing implementation of the system.

In "What is a Software Architect," we identified the role of the Software Architect as:

• The software architect has overall responsibility for driving the major technical decisions, expressed as the software architecture. This typically includes identifying and documenting the architecturally significant aspects of the system, including requirements, design, implementation, and deployment "views" of the system.


• The architect is also responsible for providing rationale for these decisions, balancing the concerns of the various stakeholders, driving down technical risks, and ensuring that decisions are effectively communicated, validated, and adhered to.

Successful Software Architects recognize the need for an explosive Software Architecture Document that maximizes the four C's.