Architecting Value

Five Implications of "All Architecture is Local"

In my earlier post I argue that to provide value quickly, architecture needs to be thought of in the context of local needs more than enterprise needs. Here are five implications of architecting locally:

1. Solve a local problem, not the enterprise problem. Making the resolution of a line-of-business problem instead of an enterprise solution will provide more defined scope, focus, and potentially better sponsorship to the project. This will also improve the credibility of the architecture practice in the long run - pointing to tangible success stories and building advocates among stakeholders.
2. Pick the right local problem. Picking the right problem space to go after can be challenging - part of our criteria is to go after those areas where the business is already focused and where they are investing. We try to keep the business problem in focus rather than the solutions we're driving. (i.e. resolving account planning instead of Microsoft Dynamics CRM). In general, also tend to focus on areas where there is a heavy dependency on process or system integration. I think integration is an area where the value of architecture becomes more clear.
3. Build a roadmap with shorter execution milestones. Not too many business stakeholders will have the patience to wait a few years for your grand enterprise solution. They need a roadmap that provides results much faster. 
4. Forego elegant solutions for short-term results. Often the enterprise solution has a lot of components and can't operate effectively until they are all in place. Accept that some pieces are just not going to work well as you build out the capability. This may even mean having parts that are *shudder* manual. Be upfront about those limitations but be clear about the value that is being delivered in the short-term. 
5. Design for modularity. While trying to deliver the right local outcome, bear in mind that the solution may need to scale for other businesses or the immediate business itself may change. Don't design too tightly to the local need - bring modularity and flexibility to the design so that downstream change will be easier.

 

All Architecture is Local

My first career out of college was as a nonprofit lobbyist in Washington, DC. It was an education in many core principles of politics, including the famous saying from former House Speaker Tip O'Neill, "all politics is local." 

Speaker O'Neill coined this phrase to describe the lesson he learned from his first and only electoral defeat (running for Cambridge City Council as a senior at Boston College) "that a politician's success is directly tied to his ability to understand and influence the issues of his constituents. Politicians must appeal to the simple, mundane and everyday concerns of those who elect them into office. Those personal issues, rather than big and intangible ideas, are often what voters care most about."

In this respect, architecture is much the same. We have big and intangible ideas that are about driving value broadly yet many customers are focused primarily on their local concerns. For some, this means changing the language that we use to describe architecture - essentially taking lofty ideas and concepts and translating it into more tangible concepts that our stakeholders can digest.

For example, I don't use the word "artifact" to describe architecture work products - I use the term that's less arcane and more familiar - "deliverables." Tony Scott, MSIT's CIO, an former chief architect at General Motors says that he didn''t even use the word "architecture" with his clients because he was concerned that it would conjure up images of ivory towers instead of tangible business value.

I think Tip O'Neill's advice, however, goes beyond simply spinning a big or national idea into something more palatable at the local level. It's about making the interests of local constituents the focal point of the effort and using that lens to look at the big ideas. Most Members of Congress spend a considerable amount of their time in their home districts, listening to their constituents. They have district staff, whose job it is to help constituents with problems that they bring to their representative. The call or letter from a local constituent has far more weight in a Congressional office than non-constituents. Walk into the DC office of your Representative and see how the staff treats you when they find that you're a constituent. It matters a great deal to their success and so every good politician invests in their local constituency.

I've seen plenty of architecture practices lose sight of this as they pursue lofty, enterprise-scale solutions such as master data management, enterprise integration platforms, SOA, and data warehouses, to name a few. I'm probably not alone in having sat through too many Inmon versus Kimball debates.

I've worked on a number of platform projects where we looked at scenarios that ran across a gamut of organizations and tried to design a solution that would fit across a myriad of needs. While these projects succeeded, they were often challenged by lack of clear ownership/sponsorship, clients that were disengaged because we weren't focused on trying to solve just their problems, long delivery times,

At the end of the day, all architecture is local. Architects need credibility if they are to succeed.  If the architecture doesn't address the tangible need of a line of business with a problem, what use is it?

This Week in Bad Architecture: Sliding Into the Grave

This is another slide I use in my "Architecture 101" deck. The point that I make about this particular picture is that architecture is not just about performance. In this example, both the slide and the gravesite perform exactly as they should. Architecture is also about the broader context in which we build solutions.

That said, having a gravesite to point to would be handy when I'm trying to get my kid to play safely at the playground.

Go Local! Making Capabilities Relevant to Your Line of Business

The challenge of an enterprise capability taxonomy is that it usually doesn't resonate with the lines of business. When I first took Microsoft IT's capability framework to our sales businesses, I got fairly direct feedback that the taxonomy didn't resonate. (I believe the technical term of art is "they puked all over it.")

Their issue was that within the enterprise capability taxonomy (internally referred to as the Business Capability Hiearchy (BCH)) wasn't organized in the way that they thought about their business. They had a framework in place already that organized their processes into three major areas - none of which were really reflected in the BCH. These three areas were what they considered their L1 capabilities.

When you clicked down from the L1 into the L2 and L3 capabilities, then you started to see a lot of similar taxonomy - pipeline forecasting, customer segmentation, etc. From the perspective of the business stakeholders, however, this detailed view was irrelevant. Their assumption was because I didn't have a capability framework that was organized in the same way that they viewed their business, they assumed that I didn't understand their business. This was a non-starter as far as they were concerned. It probably goes without saying that it's difficult to gain any traction as an architect (or nearly any profession) if your customers don't think you understand their situation. 

When you think about it, having a hierarchy is not all that important. Hierarchies - certainly at the topmost levels - are just ways to organize or classify things that are further below. There are lots of ways to organize things. For example, if I took a set of Legos, there are at least two ways of organizing it - by color or by the type of block. Neither organizing structure fundamentally changes the block itself.

The capabilities - which I think are at the L3 or L4 level - are the Lego blocks. They can be organized in lots of different ways. So there's no point really in trying to enforce an enterprise way of organizing these blocks on your business unless a) you enjoy irrelevance; or b) the enterprise view actually resonates for your line of business.

Instead, you want to "Think Local" - present the capabilities in the frameworks that are going to resonate with your business stakeholders. Generally, at the capability level - which is fairly discrete and defined - there won't be too much disagreement that those are the right capabilities. In fact, this is what I did. I took the framework our sales business had, took a subset of relevant L3 capabilities from the enterprise framework, and recast them in the sales framework. Didn't change the naming of any of the L3 capabilities and ended up getting validation that this was, in fact, the right model. A colleague who'd started out as a strong opponent became an advocate.

In general, I try to ensure capabilities are articulated in the business language so that there's no confusion. When there's a conflict between multiple lines of business, the best thing to do is to be sure that the capabilities are clearly defined.

What you don't want to have are two capabilities that mean the same thing; in this case you want to get to one. If the two groups can't agree on which (assuming that you've already tried to get them to align), pick the best (or make up a better one) and maintain a mapped view for the business(es) that don't have their own. It's not worth anyone's time to have a long taxonomy debate. It's largely academic and the ROI on everyone's time is pretty low. 

You also don't want a capability that has two meanings. Divide that one up into something more discrete. If a line of business groups two things together, try to make the case for being more precise. Failing that, maintain a mapped taxonomy. Again, there's not enough ROI to have a debate and all it does is convince your business that you're not interested in providing value.

I won't say there isn't a downside - depending on the flexibility of your tools, manual management  can get tedious - especially if you want to roll up attributes captured at the capability level and show them at a higher level of abstraction. In my view, that manual effort is worth the credibility gained with your business stakeholder.

Capability Levels: An Enterprise Perspective

Building an enterprise capability model can be challenging, but using accelerators like APQC, it's possibile to come up with a reasonable straw model quite quickly. The intent of this post is to provide what I've learned about building out the model at the enterprise level. I will complement this post with one tomorrow about how capability models should look at the line-of-business level.

For Level 1 capabilities), I think that using the APQC description of levels works just fine. Level 1 is an organizing structure and are not capabilities unto themselves. The purpose of L1 is to give your fellow architects an easy way to find the capabilities that they're looking for.

Level 2 capabilities, in my view, are also organizing structures and not capabilities. They provide much greater precision than the L1 but can also generally be used to communicate with high level executives.

At L2 is also when your design choices begin to matter. The APQC - which is more of a process model - creates several layers of organization and classification. In this example, they've created a level for "3.3 Develop Sales Strategy." I don't find this abstraction particularly useful especially given how specific the L3 capabilities are such as 3.3.1 Develop Sales Forecast. Develop Sales Forecast provides far more clarity - I would dispense altogether with Develop Sales Strategy and make Develop Sales Forecast and its siblings my L2 capabilities. By removing the original 3.3, we're flattening the hierarchy so that we can enable a more modular taxonomy of L3 capabilities. (More on that tomorrow).

One note on how you define and place your capabilities. Generally, the L1 models follow function, i.e. R&D, Marketing, Sales, etc. Don't confuse the functions with the organizations that you may be supporting. For example, our sales people are involved in getting agreements signed and managed. We have a capability to manage that called "Agreement Management." Although this is a capability that's needed in the sales organization, we don't classify it for the purposes of the model in the Sales capabilities. Instead, we group Agreement Management with other like capabilities - in the Legal capability grouping. This makes the capability easier to find for other architects and also ensures that we're not duplicating capability taxonomy in our framework.

I think that the right number of capabilities for an enterprise (at L3) is between 500-700 capabilities. This provides enough precision without having a taxonomy that is too unwieldy to steward and manage. L3 is usually a capability - that is, a business outcome unconstrained by how it's implemented by people, process, information, or technology. The APQC ones (L4 in their model) are generally written to sound more like processes.

Five Principles for Constructing Your Capability Framework

Developing a capability framework is more art than science. The framework will serve as a way to view and understand your enterprise or line of business. As a result, it will need to have some stability over time. If the capabilities are constantly changing, it will be difficult to understand and track changes in the architecture over time. The framework should also, hopefully, resonate with your stakeholders. If it doesn't, you will spend a lot of time translating what the capabilities in the framework mean. Since this is a design exercise, I've found it helpful to use these and other principles to guide the design.

1. The capability taxonomy should be stable over time. Improving understanding of the business requires a stable view of the business. Constant shifts in taxonomy will cause churn that will obscure understanding. Capabilities should therefore be defined in language that is independent of their implementation since the implementation may change. In other words, you might choose "budget review" over "quarterly budget review" since the frequency of the review may change but the essential aspect of the capability - the review of the budget does not.
2. Capabilities should be expressed in language that resonates across business areas. It is perhaps obvious that when capabilities don't resonate with the stakeholder, it reduces the credibility of the architect or causes a significant amount of translation. This problem is magnified when there are multiple lines of business that need to be supported and there isn't a common language between them. The capability framework can be used to drive consistency but it probably won't happen overnight. In general, seek a common taxonomy and translate where that's not possible. Don't create separate capabilities in your framework for each line of business that refer to the same outcome. 
3. Capabilities should be constructed in flat hierarchies. When designing a capability framework, it's important to distinguish between the actual capability and the organizing structure for the capability, especially when designing a framework that serves the enterprise or multiple lines of business. In general, we want the value to be in understanding the capability, not the organizing structure. Level 1 (L1) and 2 (L2)capabilities aren't actually capabilities - they're really just organizing structures. These may or may not resonate with your stakeholders depending on the scope of your framework. (In general, enterprise-scale L1s and L2s won't unless there is broad enterprise agreement on the taxonomy). Capabilities usually define business outcomes at  Level 3 (L3) and Level 4 (L4). The idea is to have absolute consistency at the L3 and L4 while making L1 and L2 flexible to accomodate different business organizing structures. (More on this in a later post).
4. Information-centric, not activity-centric. In a later post, I will discuss in more detail my view that information is really at the core of a company's value proposition. That said, I think that capabilities should be grouped based on the information that they're addressing as opposed to the activity. For example, this would mean that a "sales reporting" capability would be grouped with other sales-related capabilities, as oppsoed to being grouped with a reporting capability. (In this example, you may still have a generic reporting capability that sits outside of other information-centered capabilities).
5. Capabilities should be defined at the same level of granularity. This is mostly judgement but its helpful to try and keep capabilities at the same general level of abstraction for consistency. It resolves confusion and churn resulting from having different architects working at different levels of detail. The framework is especially helpful for enabling comparisons across multiple lines of business - the lower level of detail tends to only be relevant to specific lines of business. 

Where to Get Capability Frameworks

I originally meant to follow up my last post on the use of capabilities with an example of what a capability framework would look like. One of the challenges is that I don't have a ready source for enterprise-scale frameworks.

Microsoft Services has a strategic offering in which our consultants will leverage a number of generic industry models that we've developed over the past 10 years or so. I've developed a number from studying marketing material and white papers from technology consulting firms.

One excellent starting point is APQC. APQC is an organization that specializes in benchmarking studies and research. To facilitate industry and cross-industry comparisons, APQC leverages a process taxonomy developed by IBM. In addition to a generic process framework, there are also a dozen or so industry-specific frameworks, that are detailed down to a L3 or L4 level. Even if your industry isn't covered by one of the models, there's enough material for you to get started with so that you're not re-inventing too much. It's definitely an accelerator to your capability model development.

 

Get Out of the Process Optimization Prison

 

To architect for business value, we need to rescue business architecture from the process optimization prison that so many methodologies relegate business architecture. They divide the enterprise into slices - information, application, business, infrastructure, integration, etc. - treating each as equal branches of the architecture, often with their own architect. These business, information, application, and technology architects then develop the deliverables specific to their architectural domain, slap them together in a PowerPoint and voila! An architecture!

 

Okay, perhaps I'm oversimplifying a bit. More mature architecture practices understand that collaboration is a critical to successful architecture. In less mature practices, this leads to a comical situation in which architects are prevented from seeing the information that sits outside of their piece of the world. This is perhaps the logical conclusion of methodologies that overemphasize frameworks to categorize architecture information.

 

Getting value from architecture means not simply answering what information we need but also when. Many definitions of architecture define it as a bridge between business strategy and IT. A methodology that doesn't talk about how that gap is bridged - what information and when - will have difficulties succeeding. Similarly a business architect who is narrowly focused on business process, organizations , and roles may have something interesting to tell the business sponsor but risks not being able to tell a complete story.

 

The business architecture isn't about a narrow slice of business-relevant information, it's a complete view of the architecture at an abstraction that is appropriate for the business stakeholder. I have yet to meet a business leader who wasn't materially interested in the technology that supported their organization. They might not care that the interface that connects their reporting system to your enterprise data warehouse uses SQL queries but they do care that they are connected.

I believe that the business architect is the frontline for the architecture team in working with the business to connect the strategy to the operational execution of that strategy. The business architect - working with other domain architects - provides a perspective to the business stakeholder to make decisions about what investments to make.

 

At this level, the level of technical detail required is just enough to inform the investment decision. It does not require in-depth analysis of application interactions or even process decomposition.  

When we move from investment planning to solution planning, design, and delivery, that's where greater detail  around the processes, information, applications, and technology becomes more important and more traditional architecture methods take more relevance.

 

It's a level of abstraction, not scope of information. In other words, the business architecture is the business's perspective of the architecture.