Enterprise Architecture Types

Architecture Transitions

The following diagram shows the possible transitions between the four architectural patterns.

screen-shot-2016-10-11-at-22-51-33

The following paragraphs describe the possible architecture transitions and the drivers and possible reasons behind them.

Bespoke -> Monopolistic

A transition in this direction would only occur if a company managed to find a COTS package that could deliver the functionality that was not available when it developed it’s own bespoke solution.  This would indicate that they were happy to lose the investment they made in the bespoke solution; this may be due to a shift in business model, support of the bespoke solution or technology changes. With the proliferation of COTS packages this is more and more rare than it used to be, and is extremely unlikely in anything but small enterprises simply down to the main reason for developing bespoke solutions being to gain a commercial advantage using technology.

The main reason for taking this path would be that a COTS package has appeared that can deliver all of the capabilities of the bespoke package that has been developed. Based on the reasoning for being in this position – i.e. our main competitive advantage is our bespoke solution – if this occurred then the business would have significant issues in the marketplace and have to look for another commercial advantage.

Resistance to this path would include:

  • Developer ‘not invented here’ mindset
  • Business would lose investment in bespoke development and therefore would have to answer questions such as why that was done in the first place
  • Business would likely have to change it’s processes (which are the drivers for it’s success) to match the COTS package.

Bespoke ->Wild West

This is a common migration and starts when IT starts to expand and begins integrations. Due to the existence of EA skills in the Bespoke model there is a chance this can be avoided the migration can go straight to new wave, but due to differing skill sets this first step will probably be in the form of a point to point solution and will progress towards a wild west architecture. This is usually triggered when a COTS package is added to the bespoke systems landscape.

Reasons for choosing this migration include:

  • lowering bespoke systems running costs
  • reduce reliance on key staff
  • want to utilize best of breed skills we do not have internally
  • business model has changed significantly and is outside the design parameters of the bespoke system.
  • Lack of EA skills in building integrated systems

Resistance to taking this path may be in the form of:

  • Perceived reduction in flexibility of COTS packages vs bespoke development
  • Resistance from ‘not developed here’ mentality.

 

Bespoke -> New Wave

In the best case the bespoke system EA will identify the future need to replace this system and de-couple the integration. If this is done there is a change that we could move directly from bespoke to new wave but at the time of writing this is a rare transition.

Reasons for choosing this migration include:

  • lowering bespoke systems running costs
  • reduce reliance on key staff
  • want to utilize best of breed skills we do not have internally
  • business model has changed significantly and is outside the design parameters of the bespoke system.

Resistance to taking this path may be in the form of:

  • Perceived reduction in flexibility of COTS packages vs bespoke development
  • Resistance from ‘not developed here’ mentality.

 

Monopolistic -> Wild West

This is a very common transition whereby more and more systems are bolted on to the architecture using point to point solutions. Due to the lack of EA skills point to point integrations are likely to be used which will cause issues further down the line.

Reasons for taking this path include:

  • wanting to utilize a new best of breed solution
  • needing to take advantage of new technology
  • capabilities of the existing system are not meeting and cannot be changed to meet business requirements in an appropriate time scale
  • issues with supplier management
  • software has become unsupported and no direct replacement is available or appropriate
  • lack of suitable EA integration skills

Resistance to this path include:

  • specialists in the existing software reluctant to learn new tooling[5]
  • the belief that whatever the cost, the existing tooling can and should be made to support the new features.

Monopolistic -> New Wave

This  would be an ideal migration path but due to lack of EA skills and understanding of experience of the problems of the Wild West architecture and costs associated with the new wave architecture, this is a path that is not well trodden.  However taking this path early is a key to saving time and money later on.

Reasons for taking this path include:

  • wanting to utilize a new best of breed solution
  • needing to take advantage of new technology
  • capabilities of the existing system are not meeting and cannot be changed to meet business requirements in an appropriate time scale
  • issues with supplier management
  • software has become unsupported and no direct replacement is available or appropriate

Resistance to this path include:

  • specialists in the existing software reluctant to learn new tooling[6]
  • the belief that whatever the cost, the existing tooling can and should be made to support the new features.

Wild West -> New Wave

This is a path that organizations that are suffering from the inefficiencies of Wild West architectures should aim to tread. It offers many advantages but does require some thought.

Reasons for taking this path include:

  • Complexity of architecture – the connectivity of existing systems has become so tangled that change is impossible.
  • Expansion – the need to quickly acquire and on-board new brands as they are purchased – merging IT infrastructures quickly
  • Need to reduce costs due to duplication of capabilities.
  • Need to transition off large existing legacy applications.
  • Need to increase the ability to change both the business and IT architecture independently of each other.

Resistance to this path will include:

  • Perceived lack of cost benefits
  • Apathy, ‘This kind of thing has failed before’
  • Effort involved is large
  • IT staff not understanding the benefits and resisting having control, enforcement and policies.

New Wave -> Wild West

This path would take an organization from a flexible organized model to a chaotic model and is unlikely to be a path that is followed. It is however likely, and has been seen in the past, that after a failure of an Enterprise Architecture review many people return in this path after losing sight of the goals.

Reasons for taking this path:

  • Failed EA leads to resurgence of SA power
  • Business lose interest in EA work due to ‘lack of progress’
  • EA work not perceived as business benefit – lack of stakeholder management
  • May be a desired end state – in this case the EA has targeted the wrong end goal and this has not been identified. An example would include introducing middleware and just using it for point to point.
  • EA work not bringing about change quickly enough
  • Costs of EA escalating out of control

Resistance would only come from those who believed that the wild west is not a good place to be for an organization and that the new wave does bring benefits.

New Wave -> Bespoke

It is hard to imagine any organization taking this path, other than by replacing all the components in their landscape with bespoke capabilities. This would require an enterprise (large organization) believing that it could design and build all aspects of its IT landscape better and cheaper than specialized COTS players.

New Wave -> Monopolistic

This path would be trodden only by enterprises that believed that none of their best of breed systems could now offer any competitive advantage over the single system they were considering moving to. This is not to say that several parts of an enterprise’s architectural landscape may be replaced by a single system, but rarely all aspects.

Bespoke -> Bespoke

This tends to be done through general release management, it would be rare to see a large enterprise based on a bespoke system initiate a completely new development that was not an increment on the first.

Monopolistic -> Monopolistic

Aside from upgrading the existing system, this could occur for a number of reasons. If this does occur then it is likely that this is one of the few places where a big bang approach to migration will be the most appropriate.

Wild West -> Wild West

In this architecture there is continual movement and a such this transition will be happening on a weekly or monthly basis.

New Wave -> New Wave

This is possible but will take place in a piecemeal controlled manner with the new target architecture and any benefits it brings firmly understood.

[1] SAP or Oracle ERP are possible exceptions here but although I have heard they exist I have not recently seen a complete enterprise run on just one IT system .

[2] Be very wary of architectures using early agile methods as these tend to be extremely lightly documented.

[3] Give a single 10 step sequence of instructions to 2 people and they are likely to do at most 7 the same way.

[4] This is really a last ditch option as you would be doing something completely new in a production system which is highly risky.

[5] This can be prevalent to development staff close to retirement age.

[6] This can be prevalent to development staff close to retirement age.

2 thoughts on “Enterprise Architecture Types”

Leave a Reply

Your email address will not be published. Required fields are marked *