Sunday, June 29, 2014

Are you an Architect or an Engineer or a Technician?

A few days ago I had posted some thoughts about relationship between an Architect role and an Engineer role. I had referred to the Zachman Framework to explain the trade-off and dependencies in these two important role profiles. The beauty of Zachman Framework is that it does not stop at explaining only dynamics at the Architecture level but it seamlessly connects both the Business Consumer and the Technology Implementer perspectives in a simple single framework. 

Please see the simple illustration from Zachman Framework below. At the heart of below picture is the dual-relationship of an Architect role profile and the Engineer role profile as I had outlined in my previous blogpost. The Technician perspective is an interesting one and an important one. I state this because it is at the Technical perspective that the Business and Operating Models chalked up by an Architect are realised. I think that a good mature CIO or IT department has to consider the architecture in totality and offer capabilities across this spectrum. 


Architect Engineer & Technician Perspectives from Zachman Framework
All Copyrights with Zachman International

The key question of this post is, who do you think you are? Are you an Architect or an Engineer or a Technician? I suppose the answer depends on a number of factors; your organisation design, it's operating model, your own skills and capabilities. Just to give an interesting example, I used to work for a CTO who used to say, "Give me a programmer over a process engineer anyday". What he meant was, he would rather deliver better results faster working at the Technician level rather than working at the Architect or an Engineer level. 

I am not stating that his perspective is right or wrong but the point I am trying to make is having awareness of these different perspectives is important. An organisation and individuals who identify and respect these perspectives will be progressive and will make a positive difference to their business by dynamic delivery capability. What probably my CTO meant then was, he would rather work with an architect who was not shy to roll up the sleeves and perform the role of an Engineer or a Technician. Do such architects exist? This is a rare breed in my experience. 

The first, second, third and now fourth generation outsourcing models add an interesting dynamics in this discussion. For example, if a large Retailer or a large Bank outsources it's Data Centre Infrastructure and Operations to a Technology outsourcing supplier, would you call them as your Technicians? Probably yes, if you also give away your key Technician resources. Probably no, if you keep them in-house keeping an oversight on your supplier. 

As an individual an Architect or an Engineer needs to think about his / her role and capabilities within the organisation. The CIO, CTO or the IT leadership needs to think about range of capabilities they need to invest to make a positive difference to their business consumers. You can have many labels and titles if you like but what matters is understanding and delivery of Architect, Engineer and Technician perspectives. As an operating model an organisation may choose to keep these capabilities in-house or outsource them but as long as it recognises and manages their delivery, they will meet their objectives successfully. 


References used in this blogpost for further reading and credits

Monday, May 19, 2014

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: 




Friday, May 9, 2014

The Beauty of Enterprise Taxonomy and Why it Matters....

Often we, the Enterprise Architects make life difficult for ourselves (legacy of complex system thinking?) Example? We label one of the most beautiful constructs in Enterprise Architecture with a dry, "medical sounding" term Taxonomy. This is probably not a well understood construct within our community let alone our business customer community. By the way contrary to popular belief Taxonomy is not about a tax which business pays for using IT services neither it needs to be taxing as a result of overbearing IT Governance function. On a more serious note, Taxonomy is single most important construct in Enterprise Architecture. 

To use industry terms, TOGAF defines Taxonomy as something which defines terminology, and provides a coherent description of the components and conceptual structure of an information system. This is a good definition though the problem is that TOGAF then embeds this as part of Technical Reference Model (TRM). John Zachman on the other hand calls his framework as Enterprise Ontology or classification framework which I think is more holistic way of managing it. In my personal opinion and experience of doing Enterprise Architecture over past fifteen years, Taxonomy is something bigger than a mere technology terminology. I think the following are the characteristics of a good functional Enterprise Taxonomy;
  • It is a common language used by diverse stakeholders from business, IT and operations teams
  • It is a single, consistent, coherent classification system of Enterprise Artefacts
  • It is not limited to technology but a business and operations classification
  • Key things it defines are business processes, applications, infrastructure, operations and service components of the enterprise
  • It is as individual as enterprise it lives in but generally speaking it defines architecture reference models, major components and sub-components and standards associated with them. 
  • Good Taxonomy also defines interfaces and dependencies between enterprise components
It is obviously a vast area of work to explore but just to make the concept real, here are some examples...first one is example of how "Information Management Domain Model" would look like. In this case I had placed this model as part of an overarching Domain Reference Model. 

Illustrative Information Management Domain Model

To demonstrate my earlier point that Taxonomy is not just about IT constructs, here is another example from my work in the area of Retail Reference Model. The below model is a much higher level model which maps how key business functions in a vertical industry such as Retail fit together. 

Retail Reference Model by Amit Apte
It would not be possible to show all the detail workings in a single post but hopefully you get an idea of how each components then can be drilled into to show other sub-components etc. 

The benefits of a good functional Enterprise Taxonomy to an organisation are many;
  • Provides fundamental backbone for Operating Model of an Enterprise
  • Common language facilitates easier communication
  • Better diverse stakeholder alignment and management
  • Consistent and cohesive planning, modelling, tracking framework
  • Technology independent mechanism of managing Enterprise programs / projects
  • Ease of onboarding partners, suppliers and customers for enhanced collaboration
  • Better way to manage governance, reporting, tracking
  • Enhanced way of managing lifecycle of key enterprise components. 
Hopefully this post highlights some of salient features of Taxonomy. Obviously this a large body of work and it is not possible to cover all dimensions in a single post. But I simply wanted to raise awareness and profile of Taxonomy which hopefully I have to some extent. 

Blog Archive