Search Results for: business model

As mentioned in a previous post, I announced that our Enterprise Architecture team has made some very interesting investments in the area of Strategy Management and Portfolio Management in the last year via an Enterprise Architecture offering called “Strategy and Planning Service”. It’s very interesting and we’ve gathered enough experience through our mistakes and successes that I think I’m ready to share more on it to the broader community to help others. Keep in mind that we are relatively new to this area and learning more every day so I might change my opinion on some things. Here’s what I currently think.

As a bit of background, our investment in Strategy Management and Portfolio Planning is a result of our team’s need to understand Microsoft’s business strategy and connect it to changes in our enterprise architecture to inform project portfolio managers to fund the right projects and include the right scope in the funded projects. The result is an accelerated change in our architecture streamlined to achieve our corporate strategy.

We’ve decided to provide an offering from Enterprise Architecture team that essentially is a template to implement an Office of Strategy Management concept at particular areas in our enterprise. The template heavily leverages Kaplan and Norton’s Office of Strategy Management concept but is enhanced to include bits to support Strategy Formulation and Portfolio Optimization to bring an end-to-end offering for Strategy Management and Portfolio Management – one without the other is a waste of time in my opinion. We also embedded into the offering concepts to help derive platform strategy and other important Enterprise Architecture concerns like Strategy Formulation, Business Model, Operating Model, Core and Context Processes, etc. Anyway, I wanted to share with you some important details we’ve learned so far:

1. Be able to model business strategy to span the enterprise. It’s common practice to consider business strategy as scoped to a particular revenue-generating business (for not-for-profit businesses, the scope of a business strategy is often the ‘services’ they offer.) This is an awfully narrow portion of any enterprise because it doesn’t include operational businesses like Finance, HR, Sales, Support and IT. For example, Microsoft Office has a business strategy but IT wouldn’t according to common practice. With a couple of tweaks to the discipline of documenting a Business Strategy as well as make the assumption a Business is equivalent to an organization responsible for a P&L, we can connect all organizations to a cascaded business strategy that spans all organizations in an enterprise. Of course, there are several methods out there to do this. We have chosen Balanced Scorecard as a format to capture a business’ strategy in my group for a number of factors. I don’t presume this is the right choice for everyone. Anyway, using the Balanced Scorecard, we’ve implemented a process discipline of connecting Business Objectives in the Customer Perspective to a supporting organization’s Stakeholder Perspective’s Business Objectives, we get a natural cascade model that connects organization’s business strategy together. This is a rule of thumb to start with – it doesn’t always work. We sometimes have to apply some human review to modify a child’s business strategy to make it more complete while always keeping an association to the parent Business Strategy as a matter of principle.
2. Provide value-add support to Portfolio Planning to gain adoption. In order to be involved in the planning process, Enterprise Architects need to come with some sort of value proposition. We’ve built a data model to help provide the following value propositions to our planning process:
   • Data Quality. We provide quality data to the planning process facilitators that offers the following value propositions:
     • Strategy gaps, overlaps, dependencies and conflicts. This is my favorite value proposition because it was fun to formulate the data model to deliver on the promise. I also like it because having the ability to maturing strategy to the point where we can manage across the enterprise is a direct hit to being able to drive the necessary changes in our enterprise architecture to accelerate the company’s ability to deliver on strategy.
     • Providing a system with an implicit data model that forces data-entry to be consistent and of high-quality. This is important to those who are responsible for quality of the information managed in the planning process. For example, we can monitor the completeness of a Balanced Scorecard to ensure Goals exist with Objectives for all Perspectives.
   • Portfolio Prioritization. We provide guidance how portfolio managers can identify criteria to prioritize their portfolios. Essentially it’s advice how to choose business objectives from the business strategies,  how to weight them, how to associate new program demand to weighted criteria, how to analyze the results and compare against industry benchmarks, and, most interestingly, how to evaluate the prioritization criteria to effectively represent the charter of the portfolio itself.
   • Portfolio Optimization. We provide enterprise architecture analysis to look for possible portfolio optimizations such as;
     • Roadmap alignment. this is where traditional enterprise architecture work is leveraged. That is, many enterprise architecture teams develop plans for how to build out platforms, competencies, capabilities, processes, etc. Assuming those roadmaps are ‘effective’, we plug them into the planning process’s optimization activities. This is one simple way of gaining adoption of these types of enterprise architecture deliverables.
     • Strategy alignment proof through traceability of Programs to business objectives of the various business strategies.
     • Program rationalization through redundancies discovered via common processes being produced by different Programs.
     • Program dependency analysis based on shared application, platform and information to help ensure we fund all dependent Programs for other priority Programs.
     • Reuse of standard applications and platforms to ensure are in scope for programs to avoid building redundant apps and plats.
     • Possible organization adoption for program building solutions that might be useful by other organizations not currently in scope.

One really important note is that we heavily rely on our information model to deliver the above points. Getting this right is the secret sauce, the science if you will, to delivering on the above value propositions.

I’d like to tell you more about the Strategy Management and Portfolio Planning architecture work we are doing such as our Organizational Alignment, Team Model, Process Model, EA reference models, multitude of business concepts, etc but I’m not entirely confident we’ve cracked the nut on them just yet. Sharing what we have today may cause more confusion than value so I’ll wait until they are a bit more refined before sharing.

It’s time to rethink enterprise architecture people. Well, at least here in Microsoft IT’s Enterprise Architecture Team it is.

Like most EA teams, we’ve had our ups and downs and experiences leveraging various Enterprise Architecture Frameworks, methods, disciplines, etc. Like you, over the years we’ve learned what works and what to avoid.

For the past year or so, I’ve led a crack team of experts focused on aligning IT and the Business, and from this journey I wanted to share with you my current thinking. My team is called Enterprise Strategic Planning and it is a service team dedicated to enterprise-wide strategy and planning. Our initial goal is to become critical to the planning process with the intention of providing data to qualify an optimal set of IT Programs to invest in. This is quite interesting and we leverage concepts like an Enterprise Information Model for traceability all the way from Strategy to Application to Device and Location, enterprise roadmaps to describe a Business’ business capability maturity over time through Program investment, Application Roadmaps to describe an Application’s trajectory, Platform Roadmaps to describe where and when we have reusable software, etc. I can talk all day about the ESP Service team and how we do it, but in this article I wanted to share with you something that has occurred to us during our journey and describe some changes we are making that I think is ground-breaking in the Enterprise Architecture domain.

Assuming a primary goal of EA is to align IT to the Business, the problem is that most, if not all, EA Frameworks are not equipped to actually deliver on this goal. They are limited to drawing associations from IT things (eg IT Projects, Applications, Platforms, IT People/Role, Infrastructure) to Business things (eg Business Initiatives, Business Goals, Business Capabilities, Business Processes, and Operating Models). Some of the more mature EA teams have partnered with their finance department to apply financial modeling (eg Business Value Realization, Return on Investment, Net Present Value) to these associations to help describe business value in monetary terms and possibly start a chargeback model. These are all great accomplishments but at best they only capture how IT ‘relates’ to the Business. That is, these EA Frameworks and methods are more about IT transparency, not alignment.

‘Relating’ IT to the business is a problem because it is a game of catch-up. As the business changes, traditional EA approaches help IT execute through alignment techniques.The problem is that businesses are changing more rapidly every day, and IT is getting slower every day. Unfortunately, no amount of ‘relating’ IT to the business will actually bring better alignment.

Here’s the rub, have any of you out there noticed that business initiative cycles are getting smaller and IT project cycles are getting longer? How about this situation where the businesses we support have gaps in their ability to execute a strategy, or my personal favorite, where there are two or more business strategies that actually conflict with each other? How about the situation where businesses independently update their strategy? I’ve jotted down a long list of problems that need I’ve observed from time to time needing resolution in order to deliver IT alignment to the business.

Strategy out of sync with our supported Businesses:

1. Business Strategy in many businesses is not clearly defined using a common model for assessment
2. Businesses sometimes define strategy in near-isolation resulting in gaps, overlaps and sometimes conflicts
3. Business strategy changes on market demand while IT planning cycles occur yearly
4. Business interaction with IT is primarily limited to program execution details
5. Business lose sight and control of IT initiatives

Several Portfolios managed independently:

1. Several planning units in IT independently working in silos
2. Competing forces pulling the Applications and Platforms in different directions
3. Duplicate demand requests spread across multiple funding bodies
4. Gaps exist in our portfolio due to:
   • Inconsistent Prioritization Approach
   • Inconsistent Scope Management
5. IT Program Portfolio not directly associated to Business Program Portfolio
6. Lack of portfolio planning, value definition, and value realization
7. Portfolios out of date and do not reflect execution changes
8. Value is defined in high level business case but never locked down for measurement or final realization

I’m going to guess that I’m not alone here with these observations. I think these trends suggest IT is drifting farther from the business. And, to make things a little more scary, cloud computing allows the Businesses to on-board possibly VERY inappropriate enterprise software in a matter of minutes, things are going to get worse.

So, with this realization, my team has started to rethink the EA goal of aligning IT with the business. We’ve decided on a directional change to move from IT Planning in the context of the Business that require traditional EA Frameworks and methods that limit to ‘relate’ IT to the business, and instead focus on company transformation. The thinking here is to assist the company deliver on strategic goals, and of course provide traceability to IT investments, and shape IT to support the company deliver on our strategic goals. In a sense, IT planning is a byproduct of the company’s transformation.

We’ve begun to adopt business management concepts in an attempt to build a stronger understanding of how businesses are managed and incorporate them into our EA methods and tools. What’s really interesting is that there are proven best practices from business management groups to reuse. The trick for us is to ramp-up on these and adopt when we all have fairly IT backgrounds. As an indication of this commitment, we’ve recently  hired business strategy management and business initiative portfolio management subject matter experts to augment the team for this very purpose. Here are a few that we’ve begun to incorporate for example (Note, there are lots of methods to choose from – these just represent a subset that are appealing for implementation in our environment):

Michael Porter’s 5 Forces plus + Brandenburger and Nalebuff’s Sixth Force (Complementors)
Kaplan and Norton’s Office of Strategy Management and Balanced Scorecard
Alex Osterwalder’s Business Model
Geoffrey Moore’s “Core versus Context”

We’ve recently drafted a new Vision Statement, remember it is draft, and it goes something like “To Accelerate the transformation of IT, IT’s Relationship with the business and the business’ position in the market”. Two really important characteristics of the Vision Statement: 1) The word “accelerate” to imply we are a catalyst function and offer value through services to help the company achieve our strategic goals and 2) It has a destination of “business’ position in the market”. We feel that we have not fulfilled our vision until our company’s corporate-wide strategy is met.

An important note is that EA doesn’t have to own all of the new business functions that may be required in your organization in order to ‘accelerate the transformation of the company’. I would say, however, that EA should be responsible for justifying the existence of them and help establish them where they exist. For example, in our organization, we are in the process of establishing a team that will function similarly to Kaplan and Norton’s Office of Strategy Management. We took the initiative to educate the organization on the purpose and need for existence, then helped find the rightful owner and gain their commitment to implement it. EA merely has a seat at the team’s table to do our part in the new function, which usually requires us to deliver consistent models across the company for impact analysis. Unfortunately, only through experience can an EA team know which organizational functions (eg E/PMO, Finance, Change Management, Office of Strategy Management, Business Initiative Portfolio Management) need to exist and when in order to deliver on the goal of business transformation. We have yet to find a source of material that supplants sheer experience.

Adopting Strategy Management and Portfolio Management into your Enterprise Architecture function, coupled with the onus for an EA team to help the organizations build organizational functions that need to exist to deliver on enterprise-wide transformation is the breakthrough I wanted to share. I think that today’s EA Frameworks and methods don’t include these two aspects and they are limited to delivering IT transparency/relating IT to the business, which is good but not good enough to align IT to the Business.

And interestingly, we feel that a shift in  EA’s focus to ‘company transformation’ instead of ‘IT planning to align with the business’ results in the planning of IT as a sort of byproduct as it is a natural outcome transforming the company.

Although we are still learning, I’m getting really excited about this change in Enterprise Architecture. I’ll keep you updated to share with you our learning as we go on this journey.