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
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s