Operating Model

Are you an Architect or an Engineer?

by
If you share any of my professional background and work experiences, I am sure this question must have popped in your head a few times! 

Zachman Framework clearly differentiates between the above two perspectives. As a matter of fact, Zachaman Framework clearly distinguishes between six perspectives, namely; Executive, Business Management, Architect, Engineer, Technician and the Enterprise. But I find the differentiation between Architect and Engineer perspective most interesting, probably because I started my professional life as a Software Engineer and then went onto play a range of Architect roles (Business, System, EA etc.) over the last fifteen years. 

I probably can recollect a dozen instances where these roles overlapped and can also recollect may be another dozen when there was a gap between the two. That probably is more a comment on the Operating Model issues! Referring back to Zachman Framework’s definitions, the two perspectives are defined as below;
Architect and Engineer Perspectives – in Zachman Framework
All Copyrights with Zachman International
The Architecture Perspective is about the Business Logic Designers. People who manage this perspective, namely Architect role profile works closely with Business Managers to understand the key business concepts and then turn them into representations. Zachman actually names them as System Entity and System Relationship representations. The Engineer Perspective is about as Zachman calls it, Business Physics Builders. In other words, Engineers work closely with Architects to turn System representations into Technology Specifications. Zachman actually uses an example of Technology Entity Relationship specifications.


TOGAF though defines Architect roles well; it probably does not clearly differentiate between an Architect and an Engineer at a role profile level. But it does offer a good methodical (as you can expect from TOGAF) and well defined classification of view; namely, Business Architecture View, Data Architecture View, Software Engineering View, System Engineering View and so on. In my opinion that works well too as with these views an organisation can then map roles, responsibilities of Architects and Engineers onto its operating model. 

While many readers of this blog may or may not agree with precise definitions, I think this is still a good enough framework for us to start building operating model constructs around how best do Architects work with Engineers? Or vice versa! In some organisation they may be played by single role profile, in large environments it may be spread across say two or three role profiles. In an outsourced environment, Architect role may still be part of the retained IT staff and Engineers (or Engineering Services) may be procured from suppliers. I suppose, individual organisational operating model will dictate the specifics on these.


What is your experience in your organisation? How do architects work with engineers in your organisation?

References and additional reading: 


Are you an Architect or an Engineer?

by
If you share any of my professional background and work experiences, I am sure this question must have popped in your head a few times! 

Zachman Framework clearly differentiates between the above two perspectives. As a matter of fact, Zachaman Framework clearly distinguishes between six perspectives, namely; Executive, Business Management, Architect, Engineer, Technician and the Enterprise. But I find the differentiation between Architect and Engineer perspective most interesting, probably because I started my professional life as a Software Engineer and then went onto play a range of Architect roles (Business, System, EA etc.) over the last fifteen years. 

I probably can recollect a dozen instances where these roles overlapped and can also recollect may be another dozen when there was a gap between the two. That probably is more a comment on the Operating Model issues! Referring back to Zachman Framework’s definitions, the two perspectives are defined as below;
Architect and Engineer Perspectives – in Zachman Framework
All Copyrights with Zachman International
The Architecture Perspective is about the Business Logic Designers. People who manage this perspective, namely Architect role profile works closely with Business Managers to understand the key business concepts and then turn them into representations. Zachman actually names them as System Entity and System Relationship representations. The Engineer Perspective is about as Zachman calls it, Business Physics Builders. In other words, Engineers work closely with Architects to turn System representations into Technology Specifications. Zachman actually uses an example of Technology Entity Relationship specifications.


TOGAF though defines Architect roles well; it probably does not clearly differentiate between an Architect and an Engineer at a role profile level. But it does offer a good methodical (as you can expect from TOGAF) and well defined classification of view; namely, Business Architecture View, Data Architecture View, Software Engineering View, System Engineering View and so on. In my opinion that works well too as with these views an organisation can then map roles, responsibilities of Architects and Engineers onto its operating model. 

While many readers of this blog may or may not agree with precise definitions, I think this is still a good enough framework for us to start building operating model constructs around how best do Architects work with Engineers? Or vice versa! In some organisation they may be played by single role profile, in large environments it may be spread across say two or three role profiles. In an outsourced environment, Architect role may still be part of the retained IT staff and Engineers (or Engineering Services) may be procured from suppliers. I suppose, individual organisational operating model will dictate the specifics on these.


What is your experience in your organisation? How do architects work with engineers in your organisation?

References and additional reading: 


The Zachman Framework – The Perfect Tool for Operating Model Management

by

I have written previously on this blog about leveraging Enterprise Architecture as a methodology for the Operating Model creation and management. In this blog post I will briefly outline mechanism and benefits of using industry leading Zachma…

The Zachman Framework – The Perfect Tool for Operating Model Management

by

I have written previously on this blog about leveraging Enterprise Architecture as a methodology for the Operating Model creation and management. In this blog post I will briefly outline mechanism and benefits of using industry leading Zachma…

Transformation Business Model in Minutes?

by

For the past few months I have been busy helping Retail, Financial Services and Public Sector on their Digital, Multi-Channel and E-Commerce Transformation programs. Very early on in such transformation challenge, defining the business case for change …

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: