Search Results for: business model

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.

I recently had the opportunity to share an idea with a group of enterprise-level Architects and received a healthy bit of positive feedback on the idea. So, I think its worthy to share more broadly.

Most, if not all, Enterprise Architects have witnessed challenges delivering a successful Enterprise Architecture Team. I certainly have observed failings and I’ve been involved in failures directly. My Enterprise Architecture team has tried something a bit different that seems to be working and I’d like to share it with you.

The basic premise is that traditional Enterprise Architecture teams tend to lean toward delivering things like:

• Conceptual Information Models
• ‘Stick’ Governance Models
• Principles and Standards
• Position Whitepapers
• Architecture Review Board Sessions
• Consultative-only advice

While all of these are nice to have, by themselves I believe they lead to the Ivory Tower. It’s no wonder why Enterprise Architecture teams that only do the above also tend to have the following challenges:

• Struggle to prove valuable
• Struggle to be influential
• Struggle to be relevant
• Struggle to be enterprise-wide

About a year ago, my team was engaged on an enterprise problem commonly known as Enterprise Strategic Planning, which for us was about addressing three CIO concerns for the purpose of portfolio management/funding allocation of project dollars. The portfolio managers need to know:

1. IT and Business Alignment
2. Gaps and Overlaps
3. Technology Investments

At this point, we could have participated to support the Enterprise Strategic Planning effort by delivering things noted above as a traditional Enterprise Architecture would. Instead, we decided to take a different approach. We decided to adopt the Service Provider business model equipped with Service Offerings. We call it Enterprise Strategic Planning (ESP) Service and our Service Offerings include; ESP Collaborative Process, Roadmaps, Analysis, IT Proposals, Standards Alignment, and Enterprise Model/Taxonomy Maintenance. All of these are geared to delivering direct value to IT organization’s planning needs.

Mind you, we use Conceptual Information Models, principles and standards, etc but this is primarily behind the scenes and they often don’t surface in discussion unless one of our stakeholders asks a probing question of our service offerings. This is important, I’m not suggesting to ignore delivering traditional EA artifacts like CIM, position whitepapers, etc. We deliberately use them to ensure our offerings are of high quality and fidelity. High quality and fidelity are important characteristics of our brand we must manage carefully.

The paradigm shift is moving from a traditional Enterprise Architecture team to a Service Provider. We manage the ESP Service as a product line with offerings, we have a business plan, we have a strategy, we have a market with competition, we have a balanced scorecard to monitor our success to our strategy…just like any well-managed business.

A couple of interesting outcomes that are largely due to this shift:

• We no longer have the challenges mentioned above. We deliver value with explicit associations to enterprise problems. We are more influential than ever because we have voting-rights on enterprise decisions, We are highly relevant to important decisions as evident by our engagement with our company’s top brass. We are only engaged on enterprise-level problem areas.
• I don’t have the additional problem of having to sell Enterprise Architects. Previously, I would have to take time to explain how an Enterprise Information/Business/Infrastructure Architect is relevant to problems and decision making. Now, I simply deliver an offering that is required for a decision affecting our enterprise to occur. I hire Enterprise Information/Business/Infrastructure Architects to deliver the offering.
• I don’t have to ask to be influential. Our offerings are a requirement. Our deliverables are not an option. Because they implicitly have our thinking built-in, they influence our organization implicitly without having to spend a tremendous amount of effort winning relationships. Btw, I’m not saying we don’t require unbelievably strong relationship skills (aka emotional intelligence), we do.

My suggestion to you all is “Don’t build Enterprise Architecture teams/functions to have Architecture. Instead, solve enterprise problems with Enterprise Architects.”