top of page
  • Mike Walker

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:

  1. Leverage an existing standard – TOGAF

  2. 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:

  1. TOGAF adoption

  2. Enterprise Activity Model

  3. Strategic directions of the business unit

  4. Architecture vision and principles

  5. Benchmarking

  6. Long tern business requirements

  7. All projects go through the same governance model to align to the business direction

  8. Harmonized the same data model across the company

  9. Segmented portfolio by flagging solutions as strategic

  10. Leverages principles from TOGAF heavily

  11. Design based on principles

As a result they produce:

  1. Non strategic requirements

  2. Process maps

  3. Rethink the inflight projects and align them to the short term and long term business roadmap

  4. This in turn influenced the overall architecture views such as information, application and technology aspects.

Steps for alignment

  1. EAM Alignment

  2. Common Processes

  3. Data

  4. 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

1 view0 comments

Comentários


bottom of page