Category: Business Architecture (Page 2 of 2)

Business Architecture in the never-ending standardisation process of EA

At the risk of being controversial, I don’t believe enterprise architecture is about “alignment between IT and the business”.  While there is not doubt that an effective enterprise architecture practice will improve this sort of alignment, it needs to do more than improve the standing of IT or the percentage of the value pie that IT gets credit for.

Enterprise architecture is a process.  But it’s not a process of creating as-is architectures, creating to-be architectures, and then creating transition roadmaps.  These are useful deliverables and will indeed be produced – but they are no more enterprise architecture than a MS-Project plan is project management.

The process of enterprise architecture is about identifying the activities, information, or assets that you want to standardise and then managing the level of standardisation actually achieved.  It’s also important to note that this process occurs regardless of whether or not the process is called enterprise architecture.

If you look for it, this generic process of standardisation is everywhere.  Even the idea that organisations have ‘products’ and ‘services’ is a form of this standardisation.  It doesn’t require an enterprise architect to see how it would be beneficial to have some standard definition of what you do for your customers.

Another example is in the familiar department structures we see in most organisations: HR, finance, IT, etc.  It has been determined in the past – and may well still be true – that it makes sense to standardise how, for example, payroll is processed.  So you have a payroll department rather than all business units separately designing payroll processes.  It also makes sense that you’d want to standardise the way products are matched with customers.  Although increasingly separate strategies in the information age, this standardisation is traditionally achieved in this case by centralising these activities into a marketing department.

This standardisation in department groupings helps to align each organisation’s capabilities with the dynamics of the labor market.  It also promotes efficiencies through specialisation and definition of labour.  It may not always be the case, but this generic continuous process of standardisation has created these particular groupings because there is value in standardisation in these areas.

Information technology – in the general broad sense that includes processes and methods, but also in common usage as technical I.T. Information Technology – also plays a role in this standardisation process.  To use the payroll department as an example again, it is not uncommon to implement the end-to-end payroll processes beyond what is performed by the payroll department into an ERP package such as those provided by SAP, Oracle, JD Edwards, etc.  This is a process of standardisation.

The real value of enterprise architecture is recursive and somewhat tautological.  Enterprise architecture is a standardisation of the process of standardisation.  It is an attempt at defining how this on-going process of standardisation can be managed.  It’s not perfect, but it’s all we have as a method of managing this process of standardisation with any formality or openness.

Enterprise architecture as an overall integrated framework helps to standardise by providing standard categorisations, definitions, and layers in which standardisation can be achieved.  For example, Technical layers allow for standardisation of platforms, infrastructure, etc.  Whereas Application layers provide opportunities to standardise integration approaches, services, types of common application functionality, etc.  At the Information layer it is standardisation of the definitions of information items that are important so enterprise architecture frameworks assist with that.

In all cases above, the benefits of effective standardisation include reduced costs, increased agility, reduced risks, and an increased capacity for innovation.  The special challenge of the Business architecture layer is twofold.  Firstly, it provides context for the other layers.  Particularly for information and application layer standardisation, it is the only way to understand ‘effective’ standardisation of those other layers.  Secondly, the business architecture needs to identify the areas where investment [in standardisation] will deliver the greatest value.

When is comes to business architecture the standardisation process revolves around ‘capabilities’.  Remember, organisations will keep on operating regardless of what the enterprise architecture team does.  So capabilities may be existing areas where investments can be made, or potential areas based on analysis of the organisation’s customers, strategies, and other capabilities.

Not all capabilities are equal, and the types and degree of benefits that can be obtained through investment will different.  However, if you don’t know what your capabilities are then you can’t make decisions about which to focus on and which to ignore.  The next blog entry will focus on business capability mapping and how it forms the core of the enterprise architecture effort.



What, if anything, is a business architect?

It’s time to add a new topic to this blog – business architecture.  This topic will explore trends in business architecture and how the discipline of business architecture can improve the quality of IT planning, governance, and technology-enabled business transformation programs.

The question is: what is a business architect and where does the business architecture discipline fit in the context or IT architecture?  Or is that the wrong question, and could it actually be entirely the worst place to start?

Over the last 40 years information technologies have been radically integrated into business processes and business models.  At the same time, the relatively new discipline of software development has evolved and matured in order to keep up with the capacity, quality, agility, and speed-to-market improvements that business’s dependence on IT has demanded.

As these two trends collide, the importance of the software development discipline to the average organisation has peaked.  Pure software development, no longer a core competency of the average organisation, is now a commodity.  The paradox is that while software development is now a commodity the need to integrate information technology into business models is more important, and more difficult than ever.  Add to this the oft-sighted failure rates of large corporate IT projects and it could be said that while software development is a commodity, successful software development is scarce resource!  Less cynically, the real lesson that has been learnt is that successful software development is only possible within the context of a clear understanding of the business needs that drive the software development effort and the business changes that are implemented alongside the development effort.

Software development has been commoditized precisely because successful software development, and a successful IT function, must be managed within an overarching continuum of service-based management disciplines, outsourcing contracts, technology-enabled business transformation programs, and business knowledge.

So the history of the last 40 years of the IT industry has been to learn that successful business IT requires an understanding of the business.  Unfortunately, this can be as a profound a lesson as it is practically meaningless.  It’s like learning that a hand must fit a glove or that a successful puddle is made when the water exactly aligns with a hole in the ground.  This is why there are still failed projects and there are very few artifacts being developed that formally describe businesses – even when they are sorely needed.  Practical solutions aside, the lesson is in theory very simple – in order to take the risk out of IT success you need to understand the business with as much of a formal framework as you understand other parts of the solution – you need a business architecture.

It’s a natural question to follow that if you need a business architecture then you need a business architect.  After all, you develop a solution architecture by employing a solution architect.  But if we look for business architects we will simultaneously find them everywhere and nowhere.  Very few professionals with the title of business architect live up to the promise of that name.  Yet there are many who inspire us with business architect skills.  These are the business founders, the innovators of new business models, the entrepreneurs, the so-called leaders who went that one step further and created an enduring legacy in the organisation or the cause that they created.

In short, business architects are hard to find if you look in the wrong place.   You wont find a business architect if you look at your IT team or if you look at a team of architects.  Business architects are more likely to be found architecting businesses.  The only issue may be that those architects may not be sharing in a systematic way.  We must take the step of turning the successes of these people into systematic success.

We may think that business architecture belongs at the pinnacle of IT architecture because business architecture has long been an aspirational end game for IT architects.  Conceptually, business architecture is at the top of the pyramid because we’ve built a model of IT architecture that places it at the top.  In fact, if business architecture isn’t at the top of the IT architecture pyramid then the whole model breaks – and perhaps it must break.

As the software development discipline has evolved the value of the architect skill set has been continuously reconfigured and applied to more business critical domains.  While ‘system architecture’ originally might have referred to the physical systems present in microchip and motherboard design, the architecture skill set was then quickly applied to software domains.  From there it further expanded and segmented into integration architectures, platform architectures, and application architectures.  The term system architecture was then co-opted to include multiple software components – expanded again to integrate the software components and the hardware components because they make up the entire system.  This expansion and segmentation continued.  The software and hardware architectures were combined to become the ‘solution architecture’.  But the ‘solution’ wasn’t just hardware and software so the term ‘solution architecture’ was refined again to encompass the context of what was now the technical solution as well as the business process change, financial modeling, and partnerships that supported the solution.

This continuous expansion and segmentation is as complex a history of a profession as you can imagine and it’s been played out over a relatively short period of time.  The debate on the exact definitions of various types of architectures will likely continue.  But right at the top is business architect.  Unfortunately, this leaves the most important level of analysis and specialization of the architecture discipline sitting precariously on top of a towering bundle of seemingly never-ending debates about architecture artifact, views, meta-models, and architecture governance.

Business architecture is seen as the shining gold at the top of an overall architecture framework.  This is not the place for it.  Those foundations are weak, contain much that is irrelevant, and form an historic edifice that must be climbed with each discussion – losing many travelers on the way.

It’s time for business architecture to stand on its own.  Its value is potentially greater without the supporting infrastructure that has built up below it.  In fact, it’s likely that it’s not even the right foundations for business architecture.  It’s likely that business architecture has a closer relationship with economics and politics than it will ever have with IT architectures.  There is much to learn from business architecture as a type of architecture but never as a type of IT architecture.

People are using business architecture when they are analyzing the dynamics of an existing or imagined business.  But they are likely not to be designated with the role of a business architect.  They are more likely to be planning a large-scale business transformation program, or running a business, or managing risks.  They might also be advising on the same processes – based on both deep experience and deep thinking about organisations.  But even those advisors are also unlikely to want to be called a business architect.

So this blog will be an exploration of business architecture as it standards alone – not built on the foundations of information technology or IT architecture disciplines (but often alongside the application of technology to business), nor will it assume there is a specialised business architect role built into the discussion.

This is a blog about the nature of businesses and the why they create value.  It is also a blog about how this process needs to be understood by multi-disciplinary teams trying to understand, build, operate, or change businesses.  I’ve started by throwing out the misconception that business architecture is part of IT architecture – but we also need to go one step further and build a body of knowledge which doesn’t assume there is a role of a business architect who may or may not exist.  So… Where do we go from here?

Note: the title of this post is from a booked call “What, if anything, is an architect?” (  Image credits: and

Page 2 of 2

Powered by WordPress & Theme by Anders Norén