Mike Walker's Blog

BP Business Architecture Session Recap

Shatender Singh and Madhav Madaboosi, BP Plc., US

Abstract: The Open Group has determined that Business Architecture is a critical input into the decision making for an Enterprise. This presentation will outline BP’s Business Architecture methodology and will also provide a case study. BP’s varied and global business processes required the convergence of siloed business architectures to meet a simplification agenda.

 

I sat in the BP Business Architecture Session Recap this afternoon. While there wasn’t a great level of detail on tangible business architecture concepts, approaches, models and tools I didn't find there was some useful nuggets for organizations to think about when trying to build a business driven EA organization. This session turned out to be more of a case study / reflection of the BP organization.

 

BP started this journey as a result of a business led change or mandate for IT to support a transformation strategy. BP architects made two smart decisions as a result:

• Leverage an existing standard – TOGAF
• Once a method was chosen BP chose to put a heavy emphasis on business architecture approaches with a flavor of portfolio management

Their Approach includes:

• TOGAF adoption
• Enterprise Activity Model
• Strategic directions of the business unit
• Architecture vision and principles
• Benchmarking
• Long tern business requirements
• All projects go through the same governance model to align to the business direction
• Harmonized the same data model across the company
• Segmented portfolio by flagging solutions as strategic
• Leverages principles from TOGAF heavily
• Design based on principles

 

As a result they produce:

• Non strategic requirements
• Process maps
• Rethink the inflight projects and align them to the short term and long term business roadmap
• This in turn influenced the overall architecture views such as information, application and technology aspects.

 

Steps for alignment

• EAM Alignment
• Common Processes
• Data
• Application / Technical

 

Lessons learned from BP

1. Balancing geographic and localized requirements – This was very difficult with the geographies alone but when you add legacy software with constraints and specialized information.
2. Make architecture community driven and introduce social
3. Process alignment is important for other dependencies to work
4. Design authority over deployed assets is a critical element of the overall strategy
5. TOGAF helps structure the evolution of the target architecture

Business Model Generation Book

This week I talked in length about The New World of Enterprise Architecture or also referred to as Contemporary Enterprise Architecture.  This is the notion that EA is primarily business driven and focused. A few weeks back, I picked up a book called Business Model Generation. I have to say I was very impressed. I believe this should be one of the critical books on all EA’s bookshelves. This will provide Enterprise Architects who want to understand business architecture in a meaningful way a quick start guide in very practical terms. The book not only has a great look and feel but also has a ton of excellent examples on how to apply including Microsoft, Apple and even broader styles of businesses such as Open Source.

While the book focuses one Business Canvas Modeling, it provides context on how to look at other models in the business architecture and strategy planning. 

 

 

Amazon Book:

http://www.amazon.com/gp/product/0470876417?ie=UTF8&tag=businessmod06-20&linkCode=xm2&camp=1789&creativeASIN=0470876417

 

Preview of Book:

Download a 72 page preview

 

Technorati Tags: Enterprise Architecture,Business Architecture,Business Canvas

CIO's Must Make Enterprise Architecture a First Class Citizen

I am really liking the new string of articles and posts on The New World of Enterprise Architecture as I am calling it. It seems like the tone and the perceptions of Enterprise Architecture is slowly changing from pessimistic to optimistic on what EA should or could be. 

This brings me to this post, this is an important topic in that it get's to the heart of the "top down" organizational challenges.

You see that in recent series of blog posting from Dan Woods. In a more recent post called "Why CIOs Fail at Increasing Awareness Through Enterprise Architecture", he discusses that the CIO role must change. I mostly agree and would extend this a little bit more. Thanks for getting this out Dan, I think you hit the nail on the head.

Here are my general thoughts and observations based on my experience and industry observations in talking to CxO's around the world through Microsoft and out executive briefings:

• The CTO is referenced. I do not think that the CTO (at least how I define it) should be part of this equation. Just the CIO. The CTO is the Chief Technology Officer not the Chief Information Officer. If we look at these role names and what they do, they operate in different spheres. 
• I think we should give credit where credit is due. There is a transformation happening as we speak. I think this article could be spun in a much more positive light as we are seeing major players like Dell, USAA and others that have publicly talked about how they are business before technology all the way at the top levels of IT. Not only that, they are making investments in those areas. Again, noting wrong with the broader current state analysis. 
• Use just enough EA but don't over do it. EA just like anything is a very specific domain (e.g., ITIL = Operations or PMBOK = Project Management) Use the right tool for the right job, it doesn't mean however you can't leverage core principles or even elements of each to solve a problem.

In his post he gives a bit of a current state of the CIO and CTO. I think it relatively accurate with the outside few of CIO's that are more advanced than others. Ultimately it's representative of the industry. 

While it seems strange, most CIOs and CTOs (which I refer to collectively as CITOs) live in a state of limited awareness out of fear. CITOs are more comfortable running operations, evaluating technology, and developing new solutions than they are attempting to understand how and why the businesses use the systems they create. CITOs lack the temperament for the fuzzy world of business processes, and also lack the skills. If CITOs do start poking around, asking questions, developing metrics about how a business process is run, they will most likely be greeted by, “Why don’t you go do your job instead of measuring how I do mine?”

 

I think his assessment is pretty good but I think we can distill some more out of it and add a few more characteristics of the CIO:

1. Mode of Operation from Reactive to Proactive - This is the fundamental behavior in IT that has to change. 
2. Move from Order Takers to Collaborators - CIO's should help the business in a very collabrative manner not just take orders from them.
3. Run IT as a Business - There is a lot to learn here and a tremendous opportunity if more CIO's looked at IT as a Business Unit. As eluded to by Dave, a business not only creates new products and services but it also has to optimized it portfolio of products as well. And while CIO's do embark on modernization or optimization projects, it is usually a surface level technology optimization and not a true business optimization effort (e.g., desktop upgrades shifts to a business solution centric capability upgrade that may or may not involve a desktop upgrade, it could be mobility is the key.)
4. Make EA a First Class Citizen - Right now it is getting close, but not there yet. The EA charter is to help in the key areas of concern. Don't just say you are doing EA, institutionalize it!

 

For all this to occur there usually needs to be some catalyst. I come from the Financial Services space so I know this well. While there isn't a specific EA regulation like there is in the Public Sector / Government there is however, a strong lean towards EA. So you see very strong ties to EA as a result.

I agree with Dan's assessment that something has to happen (i.e, a crisis) but I think there are other entry points as well. Here are my thoughts:

1. Regulation - If there is significant risk and deemed to be regulatory this change will happen fast and will up level a industry at a time to a capability level.
2. Industry Tipping Point -Momentum in the industry makes this a forgone conclusion that this is what needs to happen. Global mind share is acquired.  
3. Viewed as a TRUE Competitive Differentiator - Right now this isn't the case broadly, but some companies are getting it. When this is made much more obvious this could be a catalyst for change as well.
4. Legal Implications - I always say, once someone is sued or put on the front page of the Wall Street Journal change happens pretty quick. I think this is true here as well. 

I do not see any evidence that IT will magically come up with this either by inwardly looking at itself nor comparing to the failures in IT overall. IT has already had an extremely poor track record with little broad and pervasive movement in this space.

But at some point, something really bad or really good happens. In a crisis, politics can get set aside as everyone takes a deep breath and focuses on how to make the business survive. In good times, a similar thing can happen in which the glow of success makes everyone feel secure. 

I also fully agree with Dan's statement shown below, as I stated above, that CIO's must make Enterprise Architecture a first class citizen.

What can we do about this?” CITOs should answer the call by suggesting the application of an established enterprise architecture methods. One of them is TOGAF, developed by The Open Group,  a consortium of IT users and suppliers that develops standards facilitating Boundaryless Information Flow™.

 

I wouldn't necessarily make everyone use an architecture method as it's not right for all problems. However, can we get people to think more like architects, yes! Can we get people to understand why we need architecture, yes! Can we get more people to appreciate the methods, activities, deliverables and key outcomes EA's wish to achieve, yes!

So with the comments around TOGAF, it's a starting point.

Use TOGAF to:

1. Get a common vocabulary within the enterprise
2. Obtain an understanding of how deliverables / documents achieve business outcomes
3. Level set on why we do specific methods
4. Think business first
5. Appreciate the rigor and science involved in Enterprise Architecture
6. Establish and leverage at multiple levels practices that scale to most problem areas like: Trade-Off Analysis, Risk Management and Transformation

So for me, I think Dan is right and what is shows it there is a great deal of opportunities that the CIO can leverage from the EA' by making them a first class citizen. They can also gain insights by shifting a portion of the way they think to be more architecturally grounded and not just technology.

More at Source: http://blogs.forbes.com/ciocentral/2011/06/23/why-cios-fail-at-increasing-awareness-through-enterprise-architecture/ 

 

Webinar: Describe your Business Architecture Using The Open Group Framework (TOGAF) in Government Enterprise Architecture

Today Architecting the Enterprise notified TOGAF community that their Chief Architect, John Polgreen, Ph. D will present on a very interesting topic of TOGAF alignment to business architecture. The webinar is entitled, “Describe your Business Architecture Using The Open Group Framework (TOGAF) in Government Enterprise Architecture” and will be hosted on January 24, 2011 at 8:30 PST.

Webinar Abstract

Once government enterprise architects accurately describe the business architecture of their agency, they then proceed to describe the technical architecture: namely the sum of the applications, data and technology (infrastructure) architectures. US Federal enterprise architectural guidance, including that found in FEA and FSAM, offers high level advice on methodology for describing technical architectures. TOGAF 9 offers highly detailed process guidance which maps closely to FEA/FSAM. The webinar will describe this mapping and show examples of artifacts that can be created using FEA/FSAM in concert with TOGAF.

Panelists will present case studies.

Participants will learn:

• How the technical architecture (applications, data and technology) depend on an understanding of the business architecture of an agency
• How the detailed guidance of TOGAF 9 maps to FEA, FSAM and other US civilian enterprise architecture guidance for describing technical architectures
• What TOGAF artifacts (catalogs, matrices and diagrams) can be useful in describing technical architectures
  

When: January 24, 2011
Time: 11:30 - 12:30 Eastern
Presenter: John Polgreen, Ph. D. (Chief Architect, Architecting the Enterprise)

Register

 

Technorati Tags: Open Group,TOGAF,Business Architecture,FEA,FSAM,FEAF,EA,Enterprise Architecture

Gartner 2010 Hype Cycle for Enterprise Architecture

Recently Gartner released the 2010 Hype Cycle for Enterprise Architecture (EA).  It's an interesting report. I'm not sure if there are really any surprises here but it worth looking at the macro themes of the report. 

You can find additional resources here:

• Full Article: http://www.gartner.com/DisplayDocument?ref=clientFriendlyUrl&id=1402513  
• Press Release: http://www.gartner.com/it/page.jsp?id=1417513

 

Source: Gartner July 2010 

What the report reveals is a set of macro themes for Enterprise Architecture.

• Traditional Enterprise Architecture that is technology focused and driven has become mainstream.
• A fundamental shift in the architecture community from IT Architecture to true Enterprise Architecture where Business Architecture is a first class citizen. EA is past the hype of the standard lip service of "We align IT with Business" and we are actually doing it. 
• Business focused EA that is executed through Enterprise Business Architecture (EBA), Business Process Management (BPM), Capability analysis and modeling, and EA Performance Management
• Frameworks are not as mature as they could be. This capability for EA is estimated by Gartner to be 10+ years out until productivity is realized. As you have heard from me in past posts and articles, I believe there is a level of pragmatism that is lost on the EA Tool providers. If they nail that, they will shorten that time to productivity significantly. 
• While there is mainstream adoption of Enterprise Architecture, the maturity level is still low. This is shown in the Hype Cycle survey it stated that 73% of EA organizations aspire to be "mature". Does this mean that those 73% are not mature? 

Gartner has published the following abstract to the EA Hype Cycle

"The artificial walls between business and IT are crashing down, and EA is the bridge to integrate business and IT," said Philip Allega, Research Vice President, Gartner. "EA's original promise was its ability to provide future safe guidance given the desires and vision of an organisation's senior leadership team. As IT roles shift away from technology management to enterprise management, EA is suited to bring clarity to these blurred boundaries, and, by 2015, increased adoption of EA processes and uses by business will further IT's alignment with the organisation's culture, future-state vision and delivery of business value outcomes."

Early-generation EA, situated on the right side of the Hype Cycle, is marked by long-standing and well-practiced approaches such as enterprise technology architecture (ETA) and architecture assurance that have been supported by traditional and federated approaches to EA. While these practices help to direct tactical IT operations, they are often supported without a business future-state vision and, as such, limit the ability for organisations to achieve and demonstrate significant business value.

"Overall, EA slipped into the Trough of Disillusionment, along with EA tools, because EA practitioners couldn't or wouldn't push EA efforts to become integrated with the business, drawing an invisible wall between the business and IT," said Allega.

As EA practitioners have become more business-focused and organisations have become more hyperconnected, new approaches of managed diversity and middle-out have emerged on the Trigger slope, forming the latest generation of EA. These disciplines are employed by end-users to try to integrate and engage with the business as a partner. One of the emerging disciplines includes a middle-out EA approach, which according to Gartner will have a transformational impact on business in the next two to five years.

"The middle-out approach enables the creation of an adaptable architecture that can help manage rapid change and enable innovation by focusing on coordination through interfaces, rather than on control through top-down standards," said Allega.

Gartner found that 73 percent of clients aspired to support "mature enterprise architecture" during the next three to five years, demonstrating that business strategy will be pervasively understood and supported within EA and across business and IT. "We predict that by 2015, the marketplace of EA practitioners will find a landscape very different from today's environment," said Betsy Burton, Research Vice President and Distinguished Analyst, Gartner.

"To prepare for 2015, EA practitioners need to ensure that EA practices are driven by a clear business vision and defined business context, and that their EA program has stabilised the practices and disciplines that are less than two years to mainstream adoption."

MEGA annonces TOGAF and Business Architecture Offerings

Over the past few weeks MEGA an enterprise architecture (EA) tools provider, has recently announced  MEGA for the TOGAF framework and Business architecture solutions. I wanted to raise awareness of this update as a news item rather than an endorsement of the product. 

MEGA promises users that they can choose to begin an EA project using MEGA for TOGAF, then move seamlessly to a wider implementation using MEGA Process (BPMN Edition) and MEGA Architecture. It seems as if these announcements are aligning business architecture with the technology/solution architecture centric TOGAF. 

MEGA says they will aid TOGAF practitioners in these ways:

• Ensure EA project success by following the comprehensive Architecture Development Method (ADM).
• Facilitate project communication to all stakeholders with the collaborative development of TOGAF 9 deliverables.
• Customize the implementation of TOGAF and ensure all projects deliverables are aligned.
• Build current and future state transition architectures and compare them.
• Identify, document, and publish technical reference models.

MEGA also communicates the value proposition to business architects as well:

• assess and streamline major investments
• improve customer information management
• consolidate post-merger, post-acquisition business units and product lines
• incorporate outsourced and partner solutions
• conform to compliance and audit requirements