Is Your Architecture Successful?

by Mike Rosen

September 2014

Architecture programs and the architects working in them are often struggling with how to define themselves, and more importantly, what work products they should be producing. One way to look at these issues is to examine the question “What is architecture?” A common, informal definition of architecture is: “the structure of fundamental elements and their relationships within an environment”.

But to some, this is too subjective. So, another good source for defining architecture is “ISO/IEC/IEEE 42010:2007, Systems and Software Engineering -- Recommended Practice for Architectural Description of Software-intensive Systems. This is a standard for how to describe architecture, not for what architecture should describe. The major concepts of 42010 include:

• A system is “a collection of components organized to accomplish a specific function or set of functions.”
• A system exists within an environment (or context), where “the environment determines the boundaries of the system relative to other systems”.
• A system has one or more stakeholders.
• A stakeholder has one or more concerns relative to the system. Concerns are “those interests which pertains to the system’s development, its operation or any other aspects that are critical or otherwise important to one or more stakeholders.”
• A system has an architecture which can be described in an architectural description.
• The architectural description can be divided into views which are “a representation of a whole system from the perspective of a related set of concerns”. Each view addresses one or more stakeholder concerns.

There are other ways to think about what is or is not architecture. For example, John Zachman distinguished between architecture and engineering in terms of primitives and composites. Another approach is to formalize architecture in terms of an architectural model (or metamodel). In fact, this is key to achieving the consistency between views that 42010 conformance requires. Still, others will question the value of an approach and be more concerned about its effectiveness than whether or not it is “architecture”.

And while it’s important to understand the structure of good architecture, it is also important to understand the purpose. What is equally important is to understand that ‘one-size-fits-all’ architecture approaches are generally not effective. Every enterprise has a different culture, structure, organization, staff, and motivation for architecture. Some will be doing architecture to reduce complexity and costs. Other enterprises will be looking to architecture to help with a merger or acquisition. Still others will be rolling out a new product or service, or some other reason. And each of these reasons will require a different approach, and have a different set of stakeholders.
So, the first step in designing an architecture program is to clearly articulate the goals of doing architecture at your enterprise. I like to go a few steps further and use the Business Motivation Model (BMM) to define the goals, strategies for achieving those goals, tactics for implementing the strategies, and objectives to measure the effectiveness of the tactics.
Typically, I do the BMM at the same time as I do a stakeholder analysis to make sure that I have identified the important stakeholders and that their goals and objectives are represented. With a better understanding of why we are doing architecture, we can then turn our attention to how.
I think fundamentally, the purpose of architecture is to create a context that influences decisions. Those might be technology selection decisions, or solution design decisions, or project selections / portfolio management decision, or business transformation execution decisions, just to name a few. Clearly, each of these decisions requires a different context and different information to influence the different people who make those decisions. We should have identified those stakeholders and decisions in the previous analysis.
It is easy to relate this back to the ISO 42010 description: different stakeholders have different concerns, which are described in different viewpoints. But it is not enough to have identified the stakeholders and their concerns. Now we need to take the definition of our architecture and program to the next step. We must also understand how best to influence the stakeholder’s decisions regarding these concerns.
My formula for architectural success is as follows:
“If you make it easier for someone to do their job using your architecture, they will. If you make it harder for them, they will fight against it.”
The formula itself is really quite simple. It seems so obvious, but as we know, achieving success is another matter altogether. So, it might behoove us to ask, how could we make someone’s job easier? Obviously, the answer to this depends on the person, their skills, their job, how they go about it, and what outcomes or decisions we’re trying to influence. I use the following set of questions to determining the structure of architectural artifacts:

1. What decisions are we trying to influence with architecture? (concerns)
2. Who makes those decisions? (stakeholders)
3. What processes do they use to make them?
4. Where are the opportunities within those processes to influence their decisions?
5. What structure of artifact would be useful: (viewpoints)

• At that point in the process
• For that individual
•  From their perspective, tools, and skill set
• And consistent with architectural principles and best practices!

So the next problem an architect has is figuring out how to answer these questions? One of the best approaches is to ask the decision makers themselves. Who knows their processes and needs better? And, if they are involved in the design of the artifacts, perhaps they will also feel some ownership and be more likely to use them.

As an example, a client wanted to develop a reference architecture for implementing SOA services. The organization was already creating services, but there were unnecessary differences and inconsistencies between them. So, we got a few of the more senior developers together and asked them “How do you create a service?” This led to a lot of follow on questions like “Have you thought about so and so?, Why are these different? What could be reused across services to save everyone time and effort? How do services relate and interact with each other? What are some of the issues? How could we address them upfront in the design?”

These are all architectural concerns that the developers typically didn’t think about. The architects could have just pounded out a solution to these issues and tried to impose it, but would that have been successful? Instead, by engaging those who make the design decisions, we got them to understand the broader set of requirements and feel ownership in the solution. The end result of the discussion was a white board sketch of a ‘design pattern’ for implementing services. Then, the architecture team took the sketch and formalized it into a proper design pattern. This pattern is widely used throughout the team for a variety of reasons:

• It has the buy-in of the ‘users’ since they were involved in creating it
• It is the right structure to influence design decisions (a pattern is perfect for this)
• Using the pattern makes the developer’s jobs easier!

So, when examining the questions of what is architecture, and how successful is an architecture program, perhaps we should be looking inward and asking: Is our architecture properly focused on the most important goals and stakeholders? Does our architecture make peoples jobs easier or harder? Is it effective at influencing the decisions that lead to achieving the architectural vision? Successful architectures can answer yes to all of these questions. Can you?