MDA and SOA are Orthogonal

To a certain degree, MDA and SOA share some common goals. Specifically, both offer the promise of isolating business/application logic from underlying technology/platform considerations. The anticipated result is significantly greater business flexibility as the business and technology aspects of the Enterprise can each evolve at their own pace.

Technically speaking, however, MDA and SOA are quite different. Model Driven Architecture (MDA) is essentially a top-down approach to designing or modeling the enterprise. It "addresses the complete life cycle of designing, deploying, integrating, and managing applications as well as data using open standards" (www.omg.org/mda/executive_overview.htm). MDA encourages modeling of the various aspects of the enterprise - including data, applications, services, technology - and leverages a comprehensive repository that includes meta-data that supports decisions and communication about the Enterprise Architecture. Further, MDA specifies the modeling tools, schema, and "languages" (e.g., MOF, XMI, CWM, CIM, etc) for this "management information."

SOA, on the other hand, is an Architectural Style "in which functionality is decomposed into small, distinct units (services), which can be distributed over a network and can be combined together and reused to create business applications" ("Service-Oriented Architecture: Concepts, Technology, and Design", Thomas Erl). SOA emphasizes design principles such as Abstraction, Autonomy, Reusability, and Composability (to name a few) that when taken together motivate and enable the decoupling of requirements for business processes from underlying implementation characteristics.

As SOA has matured beyond it's deeply technical roots, and as the industry has gained experience with large-scale adoption, it's composition has naturally broadened to include important considerations such as infrastructure support, standards, governance, and other essentials. We've also watched as SOA has moved through the typical stages of hype, only recently starting to move past over-enthusiastic and unreasonable expectations to become a more realistic component of a balanced enterprise strategy. In fact, if memory serves, Gartner's "hype cycle" positions SOA at the front edge of the "Slope of Enlightenment," just starting the climb out of the "Trough of Disillusionment." As we continue to climb the slope, the definition of SOA will continue to broaden, and the essential supporting capabilities (modeling, governance, etc) will mature and stabilize. Likewise, tool support will reach more broadly across the enterprise and influence more of the operation. As this transition takes place, SOA will continue to assume its role in providing a common language and paradigm for the unification of IT and the Business.

The result (slipping into opinion and conjecture) is that SOA will leave no room for the more rigorous and unwieldy MDA - even though they are technically orthogonal.

Agile Is Not "Make It Up As You Go"

Much to my delight, there is growing recognition that the Agile movement has attracted more than a few constituents that leverage the great principles of Agile as an excuse to "make it up as you go". It's true that Agile enables and even encourages a system that responds to change and adapts efficiently in response to the collective assessment of the team in the context of demonstrable progress and up-to-the-minute (or up-to-the-sprint) evaluation of needs and opportunities. Good stuff. It's also true that Agile emphasizes people and collaboration. And it encourages empowerment and local decision-making. Really good stuff. Unfortunately, there are many examples where these valuable leadership characteristics are being taken to an extreme or taken out of context and applied in ways that can be damaging to the team, to the project, and to the business.

I was speaking with a senior IT leader recently. This individual, for whom I have a great deal of respect, has not had much exposure to Agile and was telling me about an recent experience with a self-proclaimed "Agile" team. The primary take away from their close encounter of the Agile kind was frustration that months into a project the team could not even describe the most fundamental aspects of their objectives. It reminds me of that quote, "if you don't know where you're going, any road will get you there." Adaptation and empirical process controls are good things - incredibly powerful and valuable. But Agile doesn't mean "we have no idea where we're going or when we'll get there or which road we'll take." Agile in the absence of meaningful vision and direction is just hacking, and hacking gives Agile a bad name.

Mike posted a nice writeup on how we might look at RUP as an effective framework for organizing Agile teams at scale. In this post, title The Agile Heart of the Unified Process, he writes:

The secret to scaling Agile lies in doing just enough up front planning to ensure the teams understand the big picture of the product they are creating and have defined the significant mechanisms of communication between the various subcomponents. The RUP provides an ideal framework for helping a collection of small teams define what needs to be done in support of a large scale Agile development effort.

Whether you follow Mike's advise or some other, be sure to know where you're going on an Agile project - and be sure you've picked the right road to get you there.

Leadership - The Secret Sauce

More and more it occurs to me that one of the most important ingredients in the secret sauce of leadership is the ability to create a situation where the people feel like they're responsible for their own destiny - that what they think (and believe) has an influence. I'm reminded of that Eisenhower quote, "Leadership is the art of getting someone else to do something you want done because he wants to do it."

One way we do that is by enabling and empowering the people to advance the cause - to invent and improve the means of accomplishing the goals. To do this, it's essential that the people understand and believe that the system belongs to them. As leaders, we should reach inside and create among the people a hunger and a quest for improvement of their system. The improvement then generates from the center and radiates outward. This is "inside-out leadership" or "leadership from the center" and creates a sense of ownership that leads to ridiculous energy… and ridiculous improvement… and outrageous performance.

Taiichi Ohno, father of the Toyota Production System ("Toyota Way"), said it like this:

We need to use the words ‘you made’ as in ‘follow the decisions you made.’ When we say ‘they were made’ people feel like it was forced upon them.

The results of this leadership style are tremendous. By harnessing the energy and intellect of the team, you not only benefit from the "Wisdom of the Crowd", you instill a sense of ownership and commitment that is able to overcome any barrier - take any hill. Author Gary Hamel speaks to this in his "Management Innovation" article in the February 2006 edition of the Harvard Business Review:

“Only after American car makers had exhausted every other explanation for Toyota’s success – an undervalued yen, a docile workforce, Japanese culture, superior automation – were they finally able to admit that Toyota’s real advantage was its ability to harness the intellect of ‘ordinary’ employees.”

There's a particularly meaningful nugget in that quote… Harness the intellect of "ordinary" employees

Adaptive and agile organizations are learning organizations. Learning organizations achieve outrageous levels of performance by harnessing the intellect and energy of the people through "inside out leadership" - the secret sauce.

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.