1 year, 8 months ago

Don’t Sacrifice Your Business Architecture

Business architecture is core for an organisation’s Enterprise Architecture. Both the leading Enterprise Architecture frameworks, TOGAF and Zachman advocate Business Architecture to become a fundamental corner stone of Enterprise Architecture. Business architecture is about not just about business process modelling and business capability definition on a project to project basis. I think it is also about defining the Target Operating Model of the organisation. I have personally experienced the power of applying pragmatic business architecture to model current (as-is) and target (to-be) business operating models.
However Business Architecture is not easy to deliver on. An organisation needs skilled and experienced practitioner architects to engage stakeholders, establish relationships to understand and model the business capabilities, business processes workflows etc. Business architects should ideally also need reasonable domain knowledge of the respective business to make a meaningful contribution in the design of such model. Otherwise that individual runs the risk of becoming simply (an expensive) documentation resource.
These days often the funding for Enterprise Architecture is limited and high priority projects and programs are often competing for best resources and funding. In these situations often the Business Architecture resources are sacrificed to make way for technical architects (e.g. infra, integration). In such scenarios an organisation runs the risk of doing Enterprise Architecture without Business Architecture. This probably results in this organisation doing IT Architecture rather than Enterprise Architecture. See below graphic. 
It will probably still deliver value by bringing structure, discipline, visibility and planning to the critical IT project delivery. However these efforts risk falling short of becoming something much more meaningful and sustainable investment for business and not just IT.

I strongly feel that organisations should not sacrifice Business Architect. When resource and funding is limited, instead such organisations should find clever alternative ways to resource them. Some of the options which have worked for me in the past are;
  • Get your most important projects to fund it and then expand that to Enterprise level
  • Use your experienced application or data architect to play the role of Business Architect in the interim
  • Leverage your strategic partners / suppliers to perform this role
  • Leverage your customers / internal business stakeholders to play this role directly and indirectly. I came across an excellent real life use case of this recently. More on this in next post.

1 year, 8 months ago

Don’t Sacrifice Your Business Architecture

Business architecture is core for an organisation’s Enterprise Architecture. Both the leading Enterprise Architecture frameworks, TOGAF and Zachman advocate Business Architecture to become a fundamental corner stone of Enterprise Architecture. Business architecture is about not just about business process modelling and business capability definition on a project to project basis. I think it is also about defining the Target Operating Model of the organisation. I have personally experienced the power of applying pragmatic business architecture to model current (as-is) and target (to-be) business operating models.
However Business Architecture is not easy to deliver on. An organisation needs skilled and experienced practitioner architects to engage stakeholders, establish relationships to understand and model the business capabilities, business processes workflows etc. Business architects should ideally also need reasonable domain knowledge of the respective business to make a meaningful contribution in the design of such model. Otherwise that individual runs the risk of becoming simply (an expensive) documentation resource.
These days often the funding for Enterprise Architecture is limited and high priority projects and programs are often competing for best resources and funding. In these situations often the Business Architecture resources are sacrificed to make way for technical architects (e.g. infra, integration). In such scenarios an organisation runs the risk of doing Enterprise Architecture without Business Architecture. This probably results in this organisation doing IT Architecture rather than Enterprise Architecture. See below graphic. 
It will probably still deliver value by bringing structure, discipline, visibility and planning to the critical IT project delivery. However these efforts risk falling short of becoming something much more meaningful and sustainable investment for business and not just IT.

I strongly feel that organisations should not sacrifice Business Architect. When resource and funding is limited, instead such organisations should find clever alternative ways to resource them. Some of the options which have worked for me in the past are;
  • Get your most important projects to fund it and then expand that to Enterprise level
  • Use your experienced application or data architect to play the role of Business Architect in the interim
  • Leverage your strategic partners / suppliers to perform this role
  • Leverage your customers / internal business stakeholders to play this role directly and indirectly. I came across an excellent real life use case of this recently. More on this in next post.

3 years, 5 months ago

Are you an Architect or an Engineer?

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: 


3 years, 5 months ago

Are you an Architect or an Engineer?

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: