Operating Model

Business Architecture & Enterprise Architecture – Match Made in Heaven

by
I recently spoke at the European BPM and EA Conference in London on this topic. This blog post is a summary version of my session.

Often Business Process Management and associated discipline such as Business Architecture is seen or managed in isolation of the overarching Enterprise Architecture construct. However the Business Architecture and Enterprise Architecture complement each other well to get the best value from each other. I think that the Business Architecture is one of the key enablers of the Enterprise Architecture and makes it real. While the Enterprise Architecture offers much needed context for the Business Architecture.

It might be useful to briefly review the definitions of both Business Architecture and Enterprise Architecture before understanding issues in their relationship. 

As I have been writing on this blog, Enterprise Architecture should not be limited to the IT or Technology concerns of an organisation. Rather it should be focused on addressing much broader scope covering the business, functional, operational, financial and people aspects of the enterprise. 

There are a number of Enterprise Architecture definitions out there. A couple of my favorite ones are as follows:


Enterprise Architecture provides a strategic planning framework that relates and aligns information technology with the business functions that it supports.


Or


Practice of enterprise architecture involves developing a framework to describe a series of “current”, “intermediate” and “target” reference architectures and applying them to align change within the enterprise. Another set of terms for these are “as-is”, “to-be” and the “migration plan”.



The Business Architecture Special Interest Group of Object Management Group (OMG) defines Business Architecture as follows:

“A Blueprint of the Enterprise That Provides A Common Understanding Of The Organization And Is Used To Align Strategic Objectives And Tactical Demands.”


“Business Architecture describes the product and/or service strategy, and the organizational, functional, process, information, and geographic aspects of the business environment”

I think that though the practice of both Business Architecture and Enterprise Architecture has matured over the past few years, there certainly are some issues when it comes to these two working well together. I have summarised them in four broad arguments;

  1. Business Architecture not done at all. Enterprise Architecture teams only perform Enterprise Technical Architecture only.
  2. Business Architecture done in isolation of Enterprise Technical Architecture and then (if lucky) artificially superimposed
  3. Business Architecture and Business Context Confusion: confusion between why, what and how
  4. Technology focused governance: only conversations about technical standards, business governance disconnected from IT investment and decisions leading to critical gaps
I have tried to capture this pictorially below:

BA & EA in Isolation
This issue is getting wider acknowledgment given its strategic importance. I particularly like Randy Heffner’s work in this space. He states in one of his blogs;

“Simply positioning business architecture as a layer on top of existing EA domains is a mistake. Traditionally many organisations have pursued EA as Enterprise Technical Architecture (ETA). ETA is technology-centred.  Business architecture is business-centred. Simply layering it on top of ETA will result in tech-centred silo implementation.”


As Business Architecture Special Interest Group of Object Management Group(OMG) states, the Business Architecture defines the structure of the enterprise in terms of its governance structure, business processes, and business information. In defining the structure of the enterprise, business architecture considers customers, finances, and the market to align strategic goals and objectives with decisions regarding products and services; partners and suppliers; organization; capabilities; and key initiatives. Business Architecture primarily should focus on the business motivations, business operations and business analysis frameworks and related networks that link these aspects of the enterprise together and it should be seamlessly integrated with Enterprise Architecture efforts within the organisation. 

In my experience to tackle above listed issues, following measures can be taken by the Architecture team;

  1. Business Architecture as part of Enterprise Architecture
  2. Business Architecture drives Enterprise Architecture domains
  3. Business Architecture and Business Context clarified and integrate
  4. Business aligned Technology governance


My pictorial representation from earlier changes as below now:


BA & EA in Collaboration

Modern Enterprise Architecture teams and Enterprise Architects can not longer afford to ignore the implications of Business Architecture. Likewise, modern business architects can no longer afford to work in isolation of organisation’s enterprise architecture. 

In conclusion of this article I would like to summarize my thoughts as follows:

  1. Enterprise Architecture in isolation of Business Architecture is simply Enterprise Technical Architecture
  2. Business Architecture should guide the development of Enterprise Architecture domains
  3. Business Architecture combined with Enterprise Architecture is a powerful tool for business-IT alignment
  4. Strategic Frameworks and Models help in achieving this alignment

And as Chris Potts would argue, the Chief Executive of an Organisation should be ultimately accountable for ensuring the two come together as we would expect him or her to be the Chief Enterprise Architect of the Enterprise!

For related articles:

Enterprise Architecture – A Perfect Tool for Operating Model Management

by
On this blog I have covered the discipline of Enterprise Architecture from a number of perspectives. Enterprise Architecture (EA) can be effectively leveraged as a foundation for Industry Reference Architectures e.g. The Retail Reference Architecture. Equally effectively EA can also be leveraged as the mechanism for Business and Technology Governance as well as Technology Performance Monitoring. In this article I would like to propose that Enterprise Architecture is also an effective tool for the Operating Model management, both for the definition as well as the ongoing lifecycle management. 
It may be worthwhile visiting some industry definitions for Operating Model before we explore how Enterprise Architecture can be effective here. The definition of Operating Model varies based on the Organisational and Operational context in which it is applied and hence probably one definition may not fit all Operating Model scenarios. However if I had to choose one definition, I would like to refer to the IBM’s definition of the Operating Model (see the picture below)
IBM Target Operating Model (TOM)

IBM proposes that a Target Operating Model (TOM) helps determine the best design and deployment of resources to achieve an organization’s business goals. It provides current operational maturity assessment and roadmap to defining and/or improving organisation’s Operations Strategy. Key deliverable include business review, current operating model assessment, desired future state and change management plan roadmap.
The TOM essentially is seen here as the mechanism to link the business goals and strategy of the organisation with the roadmap for change to achieve those goals. TOM then holds together various organisation concerns such as processes, technology, capabilities, customer view, governance and partners in a single cohesive fashion.
 
Now that we have briefly summarised an illustrative Operating Model definition, let us explore how Enterprise Architecture as a discipline or practice can be leveraged as a tool for its management. There are a number of good Enterprise Architecture Frameworks available for this purpose and recent revisions of certain frameworks have further established them as leading candidates for this purpose. I do not advocate or support a specific Enterprise Architecture Framework on this blog however for illustration purposes I am going to be using the TOGAF 9 as the tool for Operating Model Management. I would like to also mention the Zachman EA framework as the other leading framework which may be equally effective or in some application scenarios it may be a better fit. 
The purpose of this article is not to explain or define the TOGAF 9 and I would highly recommend visiting the OpenGroup website for relevant documentation. However for the ease of reference, I am going to share the TOGAF ADM which is the process for Enterprise Architecture Management in TOGAF. 
The process links the Vision and Strategy of the Organisation and its business / functions with a portfolio of change programs which realises this Strategy. TOGAF uses various architecture disciplines such as Business Architecture, Information Architecture (Data and Application) and Technology Architecture as mechanism for linking the Strategy with Implementation and Governance of Change programs to deliver on the Strategy. 
The central argument which I am now going to make is that such a process of Enterprise Architecture can be seamlessly deployed and leveraged to manage the Organisation Operating Model. A number of Enterprise Architecture Frameworks and especially Zachman categorically state that the application of Enterprise Architecture should not be restricted or limited to the Information Technology systems. It is a true framework for organisation and business management. For instance applying the TOGAF to manage the IBM TOM will result in following steps / mapping. The key here is to use tools, processes, approach, templates and constructs from each of the TOGAF ADM stage to define and develop the TOM stages as seen in figure – 1. 
  1. The business goals and strategy can be defined by the Preliminary phase while the vision underpinning this is defined in Phase A. Architecture Vision
  2. The Assets and the Locations of the TOM along with key processes can be captured and defined during the Phase B. Business Architecture
  3. Certain aspects of skills, capabilities, culture and processes too can be captured in Phase B
  4. The Technology, Processes, Performance Metrics can be captured through phases C and D while defining the Information and the Technology Architecture.
  5. The sourcing options and alliances can be identified and shortlisted in phase E. Opportunities and Solutions
  6. The phase F of migration planning can be used to identify the roadmap for change through what TOGAF calls as transition architectures
  7. Finally culture which is central to TOM needs to be constantly be a driving force as well as the recipient for the requirements for change
I would like to again highlight that this is simply an illustration of managing a view of Operating Model with a particular EA approach. However a number of other variations can be equally effectively managed by similar approach. It will probably make sense to present an illustration and mapping using other EA framework such as Zachman…may be a topic for next post on this blog!

References:

Strategy and transformation for a complex world, IBM Global Services, Mar 2011

The TOGAF Architecture Development Method (ADM)

The Zachman Framework

Enterprise Architecture – A Perfect Tool for Operating Model Management

by
On this blog I have covered the discipline of Enterprise Architecture from a number of perspectives. Enterprise Architecture (EA) can be effectively leveraged as a foundation for Industry Reference Architectures e.g. The Retail Reference Architecture. Equally effectively EA can also be leveraged as the mechanism for Business and Technology Governance as well as Technology Performance Monitoring. In this article I would like to propose that Enterprise Architecture is also an effective tool for the Operating Model management, both for the definition as well as the ongoing lifecycle management. 

It may be worthwhile visiting some industry definitions for Operating Model before we explore how Enterprise Architecture can be effective here. The definition of Operating Model varies based on the Organisational and Operational context in which it is applied and hence probably one definition may not fit all Operating Model scenarios. However if I had to choose one definition, I would like to refer to the IBM’s definition of the Operating Model (see the picture below)
IBM Target Operating Model (TOM)

IBM proposes that a Target Operating Model (TOM) helps determine the best design and deployment of resources to achieve an organization’s business goals. It provides current operational maturity assessment and roadmap to defining and/or improving organisation’s Operations Strategy. Key deliverable include business review, current operating model assessment, desired future state and change management plan roadmap.
The TOM essentially is seen here as the mechanism to link the business goals and strategy of the organisation with the roadmap for change to achieve those goals. TOM then holds together various organisation concerns such as processes, technology, capabilities, customer view, governance and partners in a single cohesive fashion.
 
Now that we have briefly summarised an illustrative Operating Model definition, let us explore how Enterprise Architecture as a discipline or practice can be leveraged as a tool for its management. There are a number of good Enterprise Architecture Frameworks available for this purpose and recent revisions of certain frameworks have further established them as leading candidates for this purpose. I do not advocate or support a specific Enterprise Architecture Framework on this blog however for illustration purposes I am going to be using the TOGAF 9 as the tool for Operating Model Management. I would like to also mention the Zachman EA framework as the other leading framework which may be equally effective or in some application scenarios it may be a better fit. 


The purpose of this article is not to explain or define the TOGAF 9 and I would highly recommend visiting the OpenGroup website for relevant documentation. However for the ease of reference, I am going to share the TOGAF ADM which is the process for Enterprise Architecture Management in TOGAF. 
The process links the Vision and Strategy of the Organisation and its business / functions with a portfolio of change programs which realises this Strategy. TOGAF uses various architecture disciplines such as Business Architecture, Information Architecture (Data and Application) and Technology Architecture as mechanism for linking the Strategy with Implementation and Governance of Change programs to deliver on the Strategy. 
The central argument which I am now going to make is that such a process of Enterprise Architecture can be seamlessly deployed and leveraged to manage the Organisation Operating Model. A number of Enterprise Architecture Frameworks and especially Zachman categorically state that the application of Enterprise Architecture should not be restricted or limited to the Information Technology systems. It is a true framework for organisation and business management. For instance applying the TOGAF to manage the IBM TOM will result in following steps / mapping. The key here is to use tools, processes, approach, templates and constructs from each of the TOGAF ADM stage to define and develop the TOM stages as seen in figure – 1. 
  1. The business goals and strategy can be defined by the Preliminary phase while the vision underpinning this is defined in Phase A. Architecture Vision
  2. The Assets and the Locations of the TOM along with key processes can be captured and defined during the Phase B. Business Architecture
  3. Certain aspects of skills, capabilities, culture and processes too can be captured in Phase B
  4. The Technology, Processes, Performance Metrics can be captured through phases C and D while defining the Information and the Technology Architecture.
  5. The sourcing options and alliances can be identified and shortlisted in phase E. Opportunities and Solutions
  6. The phase F of migration planning can be used to identify the roadmap for change through what TOGAF calls as transition architectures
  7. Finally culture which is central to TOM needs to be constantly be a driving force as well as the recipient for the requirements for change
I would like to again highlight that this is simply an illustration of managing a view of Operating Model with a particular EA approach. However a number of other variations can be equally effectively managed by similar approach. It will probably make sense to present an illustration and mapping using other EA framework such as Zachman…may be a topic for next post on this blog!

References:

Strategy and transformation for a complex world, IBM Global Services, Mar 2011

The TOGAF Architecture Development Method (ADM)

The Zachman Framework

Move to Cloud Need Not Be Sensational

by

As the cloud computing adaption and maturity accelerates, a number of case studies of early cloud migration are emerging. Ironically most of such case studies often talk about success of such migration and dynamic business and technology benefits it de…

Move to Cloud Need Not Be Sensational

by

As the cloud computing adaption and maturity accelerates, a number of case studies of early cloud migration are emerging. Ironically most of such case studies often talk about success of such migration and dynamic business and technology benefits it de…

Enterprise Frameworks: In Perfect Harmony Together…

by
If you are not a practicing Enterprise Architect, words such as COBIT, TOGAF, ITIL and ZACHMAN will either mean nothing to you or will more often than not confuse you. Most IT professionals will relate these terms with concepts such as architecture framework, technology framework, standards, modelling, analysis etc. which may or may not correct depending on referring context. However, thanks to greater awareness of Enterprise Architecture in the last decade or so, it should still be easy for keen Enterprise Architecture enthusiast to find out more about the above and other similar Enterprise Frameworks. Most of above listed frameworks are available free to download for limited-time review or even free to practice if you are undertaking non-commercial internal enterprise purposes (see useful links and references below). The real question however which seldom gets asked it how do these frameworks relate with each other, if at all? How can they interact and collaborate with each other? What are considerations of such engagement across frameworks? And more importantly is it worth it from business value and relevance perspective?  Such questions would ideally demand a decent whitepaper which analyses such interactions. Given time constraints however, I am trying to present my thoughts in this blog post as an executive summary.

Before discussing a few frameworks and their potential linkage with each other, I would like to present business and IT context of such interaction. Based on my practical experience, I would propose a simple map as presented in below figure. Business goals and objectives demand strategic IT response in terms of strategic and tactical IT programs, investments and activities. They need to be governed to ensure compliance of deliverables with the business objectives. Strategy needs planning and architecture disciplines to ensure that strategic intents are given shape of tangible constructs. This is where enterprise architects convert abstract into specific plans and architectures. This is where artefacts such as business architecture, application architecture, infrastructure architecture get conceived. Such plans and architectures need to be further developed in detailed designs, transition plans and activities. More importantly, resultant IT systems and solutions are required to be operational ready and feasible. I am aware that this presents an overly simplistic picture of often much complex and complicated technology implementation reality. But the purpose here is to give a broad and high-level overview of chain of actions which need to take place in the journey of business goals to business processes, applications, solutions to their eventual technology implementations and operations.
image
Why and Where do Framework Matter?

Going back to set of initial questions which I raised in this post earlier, let us now tray and map a few leading frameworks to the above outlined concept and journey. I have picked up three leading frameworks for this purpose; COBIT, TOGAF and ITIL. COBIT framework in this map provides the overarching Strategy and Governance mechanism. It takes business goals and governance drivers as inputs and then provides a seamless mechanism to link IT Resources with planning, implementation, delivery and monitoring of delivered systems. I would like to propose that, COBIT however needs a more thorough framework such as TOGAF to further elaborate and develop the Planning and Architecture activities in the journey. TOGAF ADM provides a very good and comprehensive process discipline to take requirements through various steps such as vision, architecture, solution definition, planning and change management. At this point however, I would like to suggest that, to take the architecture to the next level of detailed design and transition planning, a framework such as ITIL will be extremely useful. ITIL takes a service view of the world in definition of systems and not a mere technology view. ITIL practitioners will put operability ahead of technology or architecture purity, and rightfully so. ITIL sees through the design through transition and operations of the service.
image
COBIT TOGAF and ITIL in Prefect Harmony

I have to clarify that, above is simply one way of arranging these very useful frameworks to work with each other. It can be argued that, TOGAF in certain instances can provide overarching umbrella for such journey from requirements to delivery. Or indeed ITIL on it’s own can be adequate to see the system design through to implementation. There is no right or wrong with Enterprise Architecture and that is the strength and weakness of the practice I would like to argue. The purpose of this post as I stated earlier was simply to showcase benefits and effectiveness of such Enterprise Frameworks work together in perfect harmony!
Now to the real question….what is the business benefit of this? Is it worth the investment and hassle? The answer is that it depends….depends on the business context. It may be worth the more complicated, complex and distributed your business requirements and resultant technology response. It may be an overkill if your requirements and responsive systems are not so complicated. In the long run however, Enterprise Architecture is about entire business and technology estate and not just one program or project and hence often you will find that medium to large size organisations will use more than one framework. In most cases, such framework do not interact well…and this is where my draft proposal above may be useful. 

References and relevant links for further reading..

  • TOGAF – The Open Group Architecture Framework
  • ITIL – Information Technology Information Library
  • COBIT – Control Objectives for Information and related Technology
  • ZACHMAN – named after inventor John Zachman

Enterprise Frameworks: In Perfect Harmony Together…

by
If you are not a practicing Enterprise Architect, words such as COBIT, TOGAF, ITIL and ZACHMAN will either mean nothing to you or will more often than not confuse you. Most IT professionals will relate these terms with concepts such as architecture framework, technology framework, standards, modelling, analysis etc. which may or may not correct depending on referring context. However, thanks to greater awareness of Enterprise Architecture in the last decade or so, it should still be easy for keen Enterprise Architecture enthusiast to find out more about the above and other similar Enterprise Frameworks. Most of above listed frameworks are available free to download for limited-time review or even free to practice if you are undertaking non-commercial internal enterprise purposes (see useful links and references below). The real question however which seldom gets asked it how do these frameworks relate with each other, if at all? How can they interact and collaborate with each other? What are considerations of such engagement across frameworks? And more importantly is it worth it from business value and relevance perspective?  Such questions would ideally demand a decent whitepaper which analyses such interactions. Given time constraints however, I am trying to present my thoughts in this blog post as an executive summary.
Before discussing a few frameworks and their potential linkage with each other, I would like to present business and IT context of such interaction. Based on my practical experience, I would propose a simple map as presented in below figure. Business goals and objectives demand strategic IT response in terms of strategic and tactical IT programs, investments and activities. They need to be governed to ensure compliance of deliverables with the business objectives. Strategy needs planning and architecture disciplines to ensure that strategic intents are given shape of tangible constructs. This is where enterprise architects convert abstract into specific plans and architectures. This is where artefacts such as business architecture, application architecture, infrastructure architecture get conceived. Such plans and architectures need to be further developed in detailed designs, transition plans and activities. More importantly, resultant IT systems and solutions are required to be operational ready and feasible. I am aware that this presents an overly simplistic picture of often much complex and complicated technology implementation reality. But the purpose here is to give a broad and high-level overview of chain of actions which need to take place in the journey of business goals to business processes, applications, solutions to their eventual technology implementations and operations.
image
Why and Where do Framework Matter?
Going back to set of initial questions which I raised in this post earlier, let us now tray and map a few leading frameworks to the above outlined concept and journey. I have picked up three leading frameworks for this purpose; COBIT, TOGAF and ITIL. COBIT framework in this map provides the overarching Strategy and Governance mechanism. It takes business goals and governance drivers as inputs and then provides a seamless mechanism to link IT Resources with planning, implementation, delivery and monitoring of delivered systems. I would like to propose that, COBIT however needs a more thorough framework such as TOGAF to further elaborate and develop the Planning and Architecture activities in the journey. TOGAF ADM provides a very good and comprehensive process discipline to take requirements through various steps such as vision, architecture, solution definition, planning and change management. At this point however, I would like to suggest that, to take the architecture to the next level of detailed design and transition planning, a framework such as ITIL will be extremely useful. ITIL takes a service view of the world in definition of systems and not a mere technology view. ITIL practitioners will put operability ahead of technology or architecture purity, and rightfully so. ITIL sees through the design through transition and operations of the service.
image
COBIT TOGAF and ITIL in Prefect Harmony
I have to clarify that, above is simply one way of arranging these very useful frameworks to work with each other. It can be argued that, TOGAF in certain instances can provide overarching umbrella for such journey from requirements to delivery. Or indeed ITIL on it’s own can be adequate to see the system design through to implementation. There is no right or wrong with Enterprise Architecture and that is the strength and weakness of the practice I would like to argue. The purpose of this post as I stated earlier was simply to showcase benefits and effectiveness of such Enterprise Frameworks work together in perfect harmony!
Now to the real question….what is the business benefit of this? Is it worth the investment and hassle? The answer is that it depends….depends on the business context. It may be worth the more complicated, complex and distributed your business requirements and resultant technology response. It may be an overkill if your requirements and responsive systems are not so complicated. In the long run however, Enterprise Architecture is about entire business and technology estate and not just one program or project and hence often you will find that medium to large size organisations will use more than one framework. In most cases, such framework do not interact well…and this is where my draft proposal above may be useful. 

References and relevant links for further reading..

  • TOGAF – The Open Group Architecture Framework
  • ITIL – Information Technology Information Library
  • COBIT – Control Objectives for Information and related Technology
  • ZACHMAN – named after inventor John Zachman

The New CIO Leader’s Top Priorities

by
“The New CIO Leader: setting the agenda and delivering results”  (Harvard Business Press, 2005) by Marianne Broadbent (Associate Dean, Melbourne Business School & Gartner Fellow) and Ellen Kitzis (Group Vice President, Gartner Executive Programs) remains one of my favourite modern IT management books. This was one of the early books to challenge conventional IT management wisdom and proposes principles, maxim and rules of modern CIO engagement with business. 

Ever a ready reference in my library, I was browsing through this over the weekend and could not resist listing “Ten New Priorities for the new CIO Leader”, here in my blog. Hopefully serves the purpose of ready reference for people in my network and my blog readers. 

Lead, don’t just manage – Leadership and management are not the same; they are complementary. A modern CIO needs to both manage and lead with personal vision and a point of view about how information and IT can make your enterprise more effective.

Understand the fundamentals of your environment – The new CIO leader knows the industry and competitive environment. 

Create a vision for how IT will build your organisation’s success – Ability to envision how to better IT-enable the business. 

Shape and inform expectations for an IT-enabled enterprise – Heart of the modern CIO role; work closely with business colleagues to identify key business needs, strategies, and drivers then articulate the IT guidelines. 

Create clear and appropriate IT governance – Effective governance enables the modern CIO to weave together business and IT strategies.

Weave business and IT strategy together – IT strategy means developing and actively managing IT portfolio to deliver success as measured by business colleagues.

Build a new IS organisation, one that is leaner and more focussed than its more traditional predecessor.  

Develop and nurture a high-performing team in your IS organisation – Know the competencies required for the new IS organisation, one that relies much more on internal and external relationships and to recruit and train for effectiveness. 

Manage the new enterprise and IT risks – A modern CIO is expected to proactively address and lead efforts to tackle ever-evolving threats such as cyber-terrorism, data privacy, and information security
.
Communicate IS performance in business-relevant language – The new CIO leader must know and communicate how IT is contributing to shareholder value and the IT value indicators that are directly linked to business value measures.

I will certainly recommend securing a copy and reading through chapters relevant to your area of priority, focus, responsibility or interest in strategic IT management. You won’t be disappointed unlike some other similar work. 

Modeling the MDM Blueprint – Part VI

by

In this series we have discussed developing the MDM blueprint by developing the Common Information (part II), Canonical (part III) , and Operating (part IV)  models in our work. In Part V  I introduced the Reference Architecture model into the mix to apply the technical infrastructure or patterns we plan on using. The blueprint has […]

Modeling the MDM Blueprint – Part IV

by

In part II and III of this series we discussed the Common Information and Canonical Models. Because MDM is a business project we need to establish of a common set of models that can be referenced independent of the technical infrastructure or patterns we plan on using. Now it is time to introduce the Operating […]

Modeling the MDM Blueprint – Part II

by

In part I of this series we discussed what essential elements should be included in a MDM blueprint. The important thing to remember is the MDM is a business project that requires establishing of a common set of models that can be referenced independent of the technical infrastructure or patterns you plan on using. The blueprint […]