8 years, 1 month ago

Enterprise Architecture Summer Camp: Preparing for Week 31.

Logistics In week 31 I will be attending the summer school dealing with Enterprise Architecture, Enterprise 2.0, Government 2.0 and organizational development. The summer school is a part of the IT University’s approach to developing an elite program dealing Enterprise Architecture and Coherency Management. The summer school will be taking place in Sweden (about a […]

8 years, 1 month ago

A Breakthrough: Maturing EA to be a Catalyst to Transform the Company

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)

6 Forces
Kaplan and Norton’s Office of Strategy Management and Balanced Scorecard BSC

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.

Categories Uncategorized
8 years, 1 month ago

The new shape of innovation – Polycentric Innovation

An interesting extract from Fujitsu I-CIO blog…There’s a revolution underway in how enterprises innovate. The discussion around the board tables at some of the world’s most admired companies is of a radical shift in strategy that will lead to unprece…

8 years, 1 month ago


 You’re all familiar with the knuckle-dragging pre-human to bipedal homo sapiens series of silhouettes that looks like it first appeared in National Geographic (anyone remember?). But this time I’m using them to illustrate some of the major points on the upward curve of software evolution.

And while neither human evolution nor software advances in correctness are as linear or as easily charted as the graphic suggests there is a similarity between them where highlights from a particular tree become visible from a single point in time, like now and to me.

Starting with Structured Programming – this was a breakthrough in code maintainability where similar logic or logic related to similar data was modularized for easier understandability. Without such an approach if/then/else clauses spanned many pages, making a code base nearly impossible to debug in a timely manner much less to hand off to another developer.

Objects overcame the division between separating code by logic or by data by allowing the developer to combine them both into an object, a single entity.

While this was a revolution to those in the craft of writing code it only helped those writing code to understand their world better and outsiders were not usually part of the arrangement of objects, class diagrams and activity diagrams notwithstanding.

Services and processes were the first entities (in this tree) to be of concern outside the development community. They could be thought of as directly supporting the business. They could be socialized and discussed by subject matter experts and process owners. Although services could be placed in repositories and called by other services and SOAP vs. REST could be argued by the technology community these were sub-plots to what was going on. And what was going on? Software usage was mushrooming and becoming a management problem that wouldn’t go away.

In other words, software was experiencing catastrophic success.

In the late 90s and early 2000s the DoD came upon the concept of capability. Each branch seemed to have its own take on how to utilize the concept and in the current DoDAF capabilities have their place in the DoDAF meta-model.

I’m here to tell you that the story doesn’t stop there. While having a meta-model is critical to keeping your feet on the ground there’s a lot more to capabilities than that.

In short, we at SenseAgility Group, are offering a Capability Based Business Architecture course that draws its inspiration from such things as IEEE 1471, MIT Sloan’s Business Operating Model, UML, BPMN, Archimate, & TOGAF. This means that we provide, through a succinct capability lens, a way to connect architecture with business architecture on a cost and value basis. Not only that but we can connect process, organization and risk/security issues in the same way.

This allows management at any level to organize software and invest in it according to their strategic plan or even to develop a strategic plan using capability based analysis. That last idea, btw, is what the Capability Portfolio is all about.


8 years, 2 months ago

A Lesson in Service Management

In the Wired magazine article on the relationship between AT&T and Apple (see: Bad Connection: Inside the iPhone Network Meltdown), the author, Fred Vogelstein, presents a classic service management problem. In the early days of the iPhone, when data usage was coming in at levels 50% higher than what AT&T projected, AT&T Senior VP Kris […]