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?

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.

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.

Capabilities: The Language of Business Architecture

 

If strategy provides the destination and general sense of direction, it is capabilities that  provide the routes and paths for getting there. Capabilities - as defined by the business architecture community at Microsoft - are business outcomes abstracted away from their implementation.  In simpler terms, they are what the business needs to do as opposed to the how.

 

Why create this abstraction? Most organizations tend to focus on the specific implementations - the roles, processes, applications and technology - which can distract from the outcome desired.

 

A simple example that my colleague, Chad Corneil, likes to use is a process in which the output is a faxed status statement. Traditional improvement approaches might examine the processes used to create the faxed statement, perhaps looking for efficiencies to increase the throughput of the statement or the speed at which it is generated.

 

What we actually care about, however, is the communication of status - that is the outcome we're driving - not how that status is communicated.  It sounds like an obvious statement that focusing on outcomes can drive better results but too often in solution-driven functions - like IT - many smart people make assumptions that the outcomes are already well understood and focus instead on the implementation. They end up with minor improvements instead of potentially transformational results.

 

Thinking about a business in terms of its outcomes allows us to consider the implementations of people, process, information, and technology from that results-orientation. We can examine how well those combinations are working to drive the desired result and make the changes necessary. We are likely to discover that we don't always need technology - better role clarity or manual process might suffice - in delivering the desired result and avoid an expensive technology solution.

Getting to Value

 

In my previous post, I mentioned that I see the business architecture as the primary bridge between strategy and operational execution. The primary function of the business architect is to translate the strategy into a plan for investments over time. This is not to suggest that there aren't other roles for the business architect to play in solution planning and design but this first function is where the business architect delivers the most value.

The figure above provides a high level view of the five phases of business architecture engagements. I use this graphic to explain the engagement to my clients . It is a simplistic depiction - the actual engagement is far from linear - but it does serve as a good communication tool for helping the clients understand the analytical approach.

 

The first phase is strategy articulation. I've said before that the role of the business architect is not to define the business strategy but to articulate it in a way that it can be easily consumed. Assuming the business is mature about their strategy, this is not a difficult exercise and can be done quickly.

 

The second phase is defining the capabilities that enable the strategy. It is helpful if you already have a map of capabilities for the business (more on this in a later post). If it exists, then it's a matter of reviewing existing capabilities to determine which are impacted. If not, it's a matter of defining what new capabilities are needed in order to enable the strategy.

 

Phase three is the assessment of the capability. This is sometimes confused with capability definition and the two activities are related but are distinct. The goal of this phase is to evaluate each existing capability to determine how well it can support the strategy. This is also where dependencies between capabilities are identified. There are multiple ways to assess the capability: heuristics, benchmarking, and more - much depends on the engagement  and I'll address this in several posts to come.

 

The fourth phase is analysis and prioritization of the capabilities. This is time spent understanding the data that has been accumulated and searching for insights or gaps that require further analysis. This is also where you align strategic-level priorities with operational-level priorities.

 

Finally, the sum of all the steps above lead to a prescriptive plan and ordering  of activities and investment - a roadmap - of how to deliver the capabilities to the desired level of performance in order to enable the strategy.

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.

Succeeding in the "New Normal"

The McKinsey Quarterly published an article (registration may be required) last month about the need for CIOs to adapt to the “new normal.” The term, coined by McKinsey worldwide managing director Ian Davis, refers to their prognosis that recovery from the recent economic downturn will not follow a traditional pattern. The economy will fundamentally restructure – a “new normal,’ marked by persistent uncertainty, tighter credit, lower consumer spending, and greater government involvement in business.”

The implications for CIOs, argue the authors, is that IT must play a much larger role in delivering on broader company goals and providing competitive advantage in the marketplace.  The authors specify three key imperatives for IT:

1.    IT must be more closely aligned with business, ideally through organization models that promote joint decision-making. Having stronger business understanding and skills will be a critical success factor for IT.

2.    IT will have to deliver more than marginal improvements in productivity and cost cutting. The goal for IT is to deliver transformational technology that radically improves the cost structure or operating model of the business.

3.    Business and IT both need to look for technology innovations that drive competitive advantage in order to adapt to the new normal.

The article does a better job of articulating the point I was making in an earlier post about IT delivering greater business value instead of focusing on marginal gains in labor productivity. I see business architecture and the role of business architects as a key accelerator of the IT-Business alignment.

There are not many functions within IT whose job is to understand the business. Business analysts, to some extent, have to understand the business processes and the business users of IT systems in order to translate business requirements into IT requirements but the altitude at which they operate not to mention their function may preclude them from having visibility into the larger business direction.

IT account mangers – to the extent that they exist – should have better visibility of business strategy and priorities, however, they may lack specific insights into the business processes and information flows that might inform their recommendations. The IT account managers I’ve worked with tend to be very senior people since they are relationship owners with the business. Typically, they aren’t going to conduct the in-depth analysis to inform  business priorities and their teams – generally made up of IT solution owners and business analysts – may not be able to fill that gap due to their functional focus.

Enter the business architect – a role whose purpose is to understand the business strategy, priorities, and operations and develop high level plans to orchestrate business and IT investment in order to enable the strategy. While this may sound like the role of account managers, the business architect is focused on how to execute the strategy while account management is focused on building and maintaining the business-IT relationship. Another way to think of it is that while the account manager is accountable for the work that the business architect is responsible for developing.

A well-developed business architecture function can bridge the gap between business and IT, providing IT with a comprehensible perspective into the business goals, priorities, and operations to inform IT investments. Moreover, this perspective can enable the opportunity to discuss how information technology can create transformational opportunities and competitive advantage for the business.

If McKinsey’s recommendation that adapting to the “new normal” requires a stronger linkages between business and IT, then business architecture is a vital enabler to make it happen.

Elements of Strategy

I begin planning with a basic assumption that it is impossible to do everything – there simply isn’t enough money, resources, or time to fulfill everything that is needed or desired. In the face of these constraints, we have to determine what it is that we should focus on. That’s  where I turn to strategy.

My former boss and mentor at Merck, Bev Rosella, developed this graphic with clients to help them understand the core components of a strategy. (Bev is now a private consultant – I highly recommend her if you need assistance with articulating your strategy).

A strategy consists of some basic elements:

Vision describes where we want to be in the future. This can be either long-term aspirational vision or a description of the short-term ideal future state, i.e. your three-year vision.

Mission describes the organization – what is the organization, what is its purpose, a high level description of how the organization creates business value.

Business outcomes describe the tangible and measurable results that the organization is driving to achieve its vision over time. This is the tangible description of the business value that is being sought.

Strategic Priorities/Actions are the key initiatives over time that describe how the outcomes are achieved in order to realize the vision.

To me, a strategy is very much like planning a trip. The vision is your final destination, the mission is your mode of travel (i.e. car, foot, a plane, etc.), the outcomes are the results you want from your trip (i.e. I want to arrive in 4 hours or I want to see these monuments on my journey), and the priorities and actions are the route that you take to get there.

A Framework for Planning

My team is somewhat unique within Microsoft IT in that we are a fairly senior team whose work spans all of the lines of business we support. We are accountable for helping our organization navigate the investment planning process and actively manage the IT portfolio. To this task, we bring a diverse range of expertise including Six Sigma, business architecture, portfolio management, and project management, among others.

We’ve developed a planning framework that we use to understand how business value is defined and how we subsequently realize it. This framework allows us to thread our planning expertise together in an end-to-end view and provide a vehicle for educating our clients about planning.

 

Business Value Definition
The first phases of planning are used to define what provides business value. These activities are represented in the semi-circle on the right starting with Strategy Development, Architecture Planning, and Demand Management.

Strategy Development is the activity of defining where the business would like to be in a 3-5 year time frame, what are the key outcomes that it is trying to achieve in that timeframe, the major change initiatives that will get them there, and the relative priority of those initiatives.

Architecture Planning is an activity of translating the strategy into business capabilities that will enable the strategy. These capabilities then must be understood in terms of their future state and compared to their current state implementation. The deltas between the current and future state and the prioritization of capabilities form the foundation of a strategic roadmap for realizing the strategy.

Demand Management is the activity of receiving and managing demand for an investment portfolio. This demand will constitute both strategic demand coming from the architecture planning work as well as tactical demands that serve near-term business interests. Managing this demands also involves performing some level of triage so as to focus only on those items that have some realistic expectation of delivering business value and normalizing the demands so that they can be easily compared. This is likely the activity in which business cases are created with ROI and other types of investment calculations to assist with portfolio optimization.

Business Value Realization
The last phases of planning are used to help realize the business value that has been defined and are represented by the activities that appear in the semi-circle on the left.

Portfolio Optimization is the activity of applying constraints – minimally funding but also other defined investment criteria – in order to determine the best portfolio of investments.

Portfolio Management is the activity of actively managing the portfolio to ensure that investment programs are on track to deliver the value that has been committed. Changes in priorities, funding, program delivery schedules , and other factors can disrupt the investment plan and may necessitate making changes to the investment plan.

The existing portfolio and its execution against business value, in turn, inform strategy development in a continuous cycle. I should note, however, that strategy is also informed by demand and other factors so the representation in the framework is a simplified understanding of planning and not meant to represent a linear process.

I will spend most of my time on this blog addressing the first two activities, partially because they represent my primary function at Microsoft, but also because I think this is the area that is most immature from a discipline perspective and less well-understood. There are other sources that are better informed than me on the downstream activities of demand management, portfolio optimization, and portfolio management so I will likely only address them in terms of their integration with strategy development and architecture planning.