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.

 

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.

The Battle of Our Times: Capabilities vs. Process

Photo by Tim Hipps, FMWRC Public Affairs

I'm a little ashamed to admit I've spent far too much of my career debating colleagues on the merits of capability versus process. In the worst example, I engaged in an intense debate on the topic in front of my vice-president, my general manager, and the chief architect of the company. My VP considers that the worst conversation she's been in in the past three years.

Who can blame her? It's largely academic, mostly cared about by architects and is frankly, and too nuanced for non-architects to really understand; certainly too trivial for a VP to be bothered with. 

The debate is really about what concept should be used as the key lens for understanding an organization. This camp is where you'll usually find the Six Sigma evangelists and business process management devotees. I'm not sure how much they'll agree with my synthesis of their position but essentially it's this: business processes are activities and organizations are largely about the activities they execute, therefore this is the appropriate concept by which to understand the organization.

In the other camp are business architects, usually. Their perspective is that organizations aren't really about activities, they are about outcomes. Activities are merely a vehicle for achieving outcomes. Most organizations care more about the outcomes (what) than the activity (how) that was used to accomplish the outcome. Capabilities - by definition - are the business outcomes unconstrained by the people, process, information, and technology used to achieve it.

As is probably apparent from what I've written so far, I strongly believe that capabilities are a better lens than processes primarily for three reasons. The first is the focal distinction between the two concepts. Business outcomes are about value - activities can be about value but not necessarily so. It's not unheard of for organizations to spend so much energy on the activity that they lose sight of the value that they're driving for. Properly defined capabilities ensure that value is always in the focus.

The second reason  is that processes don't always account for all of the outcomes that an organization cares about. In fact, there are some outcomes that are entrenched in multiple processes. Customer relationship management, for example, is a part of many processes throughout the lifecycle of the customer. This is an outcome that needs to be managed - process can't handle it very well. A capability-based approach provides visibility to the outcome without being constrained by the processes.

The third has  to do with methods - namely, most process-centric approaches are overly concerned with process-modeling. I like process models - they can be invaluable - but they aren't a panacea for making organizational improvements. That's largely because they take too long and provide too little return on investment. Process modeling is a cumbersome activity, especially at the swimlane level which many methods prescribe. An organization - especially a global, multi-national one - will likely have multiple process flows for any particular process depending on the geography, amongst other factors. At the end, there's not much in terms of prescription and instead a huge library of processes that must then be continuously maintained.

I think capability-based planning provides a more scalable approach. You start with an understanding of the outcomes, determine which high-value outcomes required the most attention, and then focus energy on dissecting only those capabilities which matter, using multiple tools including process modeling. There's no wasted effort trying to inventory processes of the sake of having a model.

That's an argument I'm willing to have, although if my VP is present, I'm likely to ask that we take it outside.

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.

This Week in Bad Architecture

Allow me to introduce my first candidate for "This Week in Bad Architecture." I find this picture hysterical and I've started to use it as the title slide for my presentation on "Architecture 101." Great picture to make the point and lighten the mood.

I spend a fair amount of my time educating business and IT stakeholders about architecture. For many it's abstract, theoretical, or simply unapproachable. It's mired in arcane language and ineffective delivery models that make the value difficult to understand.

When I introduce the topic of architecture to a new audience, I usually start with examples of bad non-IT related architecture. My reasoning is simple: good architecture can be hard to spot. A good architecture has taken into account the context in which it resides and its human use and devised a way to blend in and serve its function unobtrusively. It just works.

Poor architecture, by contrast, stands out because it works against its context or human use. I've collected a number of these examples over the years which I plan to share. I won't speak for the credibility of these images - for all I know, most if not all have been Photoshopped. The point, isn't so much that these architectures truly exist but that if they did, it is the likely result of poor planning, poor design choices, or would involve enormous expense.

I'll share what I've gathered so far but would love to see what others have accumulated. Shoot me an email at dmishra - at - microsoft.com.

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.

 

Beware of Watermelons

Microsoft is a company that heavily leverages scorecards for managing performance. Our CIO's scorecard has nearly 100 separate metrics that are used to evaluate his performance - indicated by green, yellow, or red.  Recently, he cautioned us about scorecard "watermelons," that is, items that appear green on the scorecard but are actually significantly underperforming and should be red. This happens when the scorecard fails to capture the right measure.

 

I recently had a "watermelon" experience that should be a standard risk to look out for on business architecture engagements, especially if you suspect that the organization is not strategically mature. I had an executive sponsor insist that we conduct an engagement for his organization as they were undergoing a major strategic shift. He made available some of his managers who committed nearly 20% of their time to helping us create the strategy deliverables.

 

This engagement appeared green on our scorecard since we had executive sponsorship, commitment from the client, and were making progress on the deliverables. The only problem was that the people we were working with didn't really know what the strategy was. The executives had kept the strategy close to the vest and the managers we were working with were taking their best guess.

 

This internal disconnect with the client wasn't discovered until the end of the engagement when the SOAP was presented for validation. The executives were expecting something that articulated their transformational strategy and instead something that showed incremental improvements. We were green when it came to the engagement but bright red when it came to the actual content .

 

It was a terrific lesson - I had allowed the fact that I had engagement from the client obscure the fact that I didn't have the right level of engagement. In retrospect, I should have structured more frequent and earlier reviews with the sponsor to ensure that we were going in the right direction. The deliverables that I'm prescribing are primarily listening devices - they should be used often to validate whether you are on the right track to avoid watermelons.

Using SOAPs to Gauge Strategic Maturity

Many people who work in IT organizations labor under the assumption that their business clients have a clear understanding of their strategy - it is simply waiting on a shelf for someone to ask for it. The reality, of course, is that maturity varies from truly visionary organizations to the constant fire drill teams. I've found that the development of the SOAP can be a good indicator of my clients' strategic maturity which is why the process is just as important as the end deliverable.

 

For an organization that is mature in it's strategic discipline, the SOAP is a painless exercise. They can articulate their vision and mission; they have clear understanding of their priorities and the outcomes they're driving and the actions they need to take to get there. This is - at most - a 2-3 hour workshop with a week to tweak over email and perhaps a follow-on meeting for validation.

 

Immature organizations struggle with SOAPs. They may question the value of the activity, since the organization's strategy should already be obvious to everyone who's involved. Their strategic priorities will read like motherhood and apple pie -  "Beat the competition," "Grow Revenue" and "Satisfy Customers."  I had a client once that even articulated that their strategic priority was to "Win Everywhere."

 

(A priority should be more specific and actionable. A simple test I use is to ask myself - if I were a general (or a VP), could I use the priority  to answer credibly what my strategy is? Example: "General, what is your strategy to win the battle?" "My strategy is to 'Win Everywhere.'")

 

A key indicator of low strategic maturity can be gleaned from how the SOAPs are constructed. If the construction is generally top-down, the maturity is tends to be higher than when the activity is bottom-up. Low maturity organizations will begin with a focus on the imperatives which amounts to documenting their current and near-term initiatives. They will then articulate priorities by categorizing the imperatives.

An organization with a strong understanding of its strategy, however, does not need to categorize imperatives to identify priorities. It can easily define the priorities and organize imperatives which fit the priority.

 

Knowing the strategic maturity of the organization won't directly benefit the organization - it's really helpful for you to know how to handle the organization throughout the engagement. The value of the work will be obvious to the strategically mature organization; you will spend much more time explaining the value to organizations that are less mature. Managing those expectations will be critical to your success.