Hottest Posts in 2008

2008 was a good year for the practice of software architecture. Good progress is being made throughout the industry in recognition of Architecture as a distinct discipline, and the maturity of the discipline was advanced by the excellent writings of a host of passionate practitioners. Looking back at the year on SoftwareArchitecture.com, I found it interesting to note the most popular posts of 2008. People are clearly interested in understanding the profession and reinforcing their practice. Let's keep it up!

The top 10 most popular posts of 2008:

1. What Is Software Architecture?
2. Good Architecture Descriptions are Explosive
3. Service Design Principles (the Contract Story Continues)
4. Most Important Competencies of the Software Architect
5. What is a Software Architect?
6. The Architect is Accountable!
7. Progressive Refinement of Estimates (aka The Transmission Repair)
8. The Proactive Architect
9. Governance Without Goodwill is Dead
10. The Making of a Governance Anti-Pattern?

I hope you have found something thought-provoking. As always, I love hearing from you.

Architects Are Pigs

Remember the story of the barnyard breakfast?


The chicken and the pig agree to co-host a barnyard breakfast for their friends. The chicken suggests they serve bacon and eggs. The pig quickly responds, "No way. For you, bacon and eggs is simply involvement. For me, it's total commitment!"


Leadership and accountability go hand-in-hand. As elaborated upon in The Architect is Accountable! and The Proactive Architect, the Architect is expected to lead by example. This sort of commitment means living in the trenches with the project teams, establishing goodwill, and earning respect.

Another way of saying this is the Architect must possess "personal authority." This is quite different from "position authority" (which may or may not be present as a result of the title and role of Architect). Personal authority is a principle enabler of leadership and is critical to the effectiveness of the Architect. Decades of research have shown that personal authority is rooted in several factors, including certain personal and social characteristics. However, the number one source is universally tied to performance-oriented attributes such as ability, knowledge, accomplishment, commitment, and responsibility.

As an Architect, one of your primary responsibilities is to influence. Your ability to provide influence is connected to the extent to which others view you as credible and acceptable - the extent to which you possess personal authority. And personal authority emerges from performance, visibility, and results - the kind of results that are only possible if you're in the game and personally invested.

Are you demonstrating "Pig Commitment"?

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.

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.