Architecting Value

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.

Rethinking Business Value

In my first post, I asked the question – “what constitutes business value?” I argued that it’s not simply delivering what the client asks because sometimes the client doesn’t have the right perspective. Most of my clients begin their conversation with me by talking about their IT problems. These conversations are typically characterized by the focus on IT systems and the immediacy of the need - they need better functionality from their CRM solution to remove some manual step or they need a specific report. In an order-taking IT organization, we might promptly write down the requirement and try to figure out when we will slot it into a release calendar. The customer’s requirement is heard, understood, and a plan is presented for meeting the requirement. This provides the customer with the value they’re looking for, right?

What’s missing from this conversation, in my mind, is context. Why do they need this particular report or functionality? What is the business goal that they are ultimately driving towards? If we have a good relationship with our clients, we may already know the answer to this question. There are others, though, that we need to have good answers for such as what are the other goals that the business is driving? Over what time horizon? How does this goal or requirement stack up against the others?

Absent a strong understanding of the business goals, strategies, and priorities, information technology organizations risk limiting the value they bring to their business clients.  Deloitte’s Center for the Edge recently published results from their “Shift Index” which found that while labor productivity has more than doubled in the past forty years, return-on-assets have declined by 75%. The researchers point out that much of the capital investment made by companies in the past forty years has been in information technology leading them to the conclusion that IT has failed to deliver significant value. Deloitte hypothesizes that "technology investment... has been overly focused on an industrial-era model. 'It’s been all about standardization and automation of business processes... Until and unless companies learn how to harness knowledge flows, the impact of the technology will mainly be continuing competitive pressure.”

Anecdotally, I have found this to be true. Many IT planning meetings with business clients amount to identifying manual processes and targeting them for automation, irrespective of the value that such automation might bring. The key success measure for one of Microsoft IT’s major strategic programs is being measured in labor productivity. While this isn’t inherently wrong, the question remains, can IT deliver greater value to its customers?

Most non-IT senior executives believe so. A McKinsey & Company survey (registration required) found that while most were satisfied with the ability of their IT divisions to provide basic IT services such as email, workstations, office productivity software, etc., what they found lacking was IT’s ability to provide transformative new business capabilities and innovation. These executives believed that IT was overly focused on creating greater efficiency – a view echoed by many IT executives who were also surveyed by McKinsey.

I am suggesting that IT leaders set a high bar for delivering business value – not just incremental improvements in productivity, cost reduction, and efficiency but significant, transformative changes that leverage the full potential of IT as an engine of the business to achieve its goals and objectives. IT organizations that can accomplish this are ones that have strong understanding of how the business functions and visibility into their clients’ strategy and goals.

This is no short-term journey for most IT organizations. This can involve a major paradigm shift in how we think about the relationship between IT and our business clients; it means changing how we think about the process by which we engage the business in strategic and investment planning; it involves skill sets that are not traditionally found in IT organizations.  In my next post, I will describe a planning framework that can be used to translate business strategies into investment plans.

Architecting Value

When I joined Microsoft, my general manager offered a simple description of my charter – to focus our IT group on doing the right things instead of how we do things right. The right things, in his view, are the things that provide business value to our clients. This seems like a simple task but in a large, global enterprise, it can be surprisingly challenging.

For starters, what constitutes business value? If our client tells us that they want something and it is delivered, isn’t that value? I would argue that it really depends on the nature of the relationship between the IT organization and its business client. Sometimes the business doesn’t have the right perspective on what will deliver the right value.

At my previous company, for example, I was working on a project to improve the relationship that that the company had with some key customers. The executive sponsor listened patiently while we explained our analytical process and then said, “This is great, but for my money, I’d better see a portal.”  In a typical business-IT relationship, the IT representative might begin asking what kind of features or requirements are needed for the portal and begin plans for development. The client gets what they want so value is delivered, right?

Well, in this case, we did the analysis and found that these particular customers were highly unlikely to visit a portal. They desired information from the company, but preferred a human interaction. We took back our findings along with recommendations for other solution options that made it easier for these customers to reach a knowledgeable person at the company. The sponsor listened to our analysis and promptly accepted our recommendation and avoided wasting IT dollars on a portal that no one would visit.

This outcome is what I believe both business and IT leaders want from their relationship – ensuring that IT investment dollars are spent on solutions that help the business achieve its business goals – in other words, providing value. Driving this outcome, however, depends on some key assumptions and behaviors:

· Generally, long-term business strategies and goals should inform IT investment priorities

· Both business and IT need to have the discipline to test assumptions and conduct analysis with proper rigor before making solution decisions

· The relationship between IT and its business clients needs to be one of “trusted advisor” as opposed to “order-taker”

This is no small task for typical IT organizations – some business organizations are focused on near-term results and don’t make sufficient investment in articulating their long-term direction. High performance organizations are often quick to leap to solutions rather than invest the time in problem analysis. Many IT groups don’t have the type of relationship in which they are at the table helping to define business strategy and goals.

These challenges and a myriad more are mine as I try to transform the way that Microsoft IT collaborates with our business clients to plan and invest more deliberatively – what I call architecting value. The goal of this blog is to provide a practitioner perspective on how business strategies are translated into executionable plans that deliver value. I hope to share knowledge, best practices, lessons learned, methodologies and frameworks as well as learn from other business and IT planners.