Enterprise Architecture Types

New Wave

These are the new wave architectures which seek to provide structure and direction in Wild West Enterprise Architecture’s. The key driver for this tends to be that we need the flexibility and integration of the wild west style architecture but we do not need the lack of direction and organization.

New wave architectures need clear direction both from the business and IT, principles and enterprise. Recognition should be apparent that both IT and business have different needs and drivers and should be able to flex and evolve independently of each other. Change should be speedy and the architecture needs to be designed to accommodate this.

Note that this architecture is not achieved by ‘organizing the spaghetti’ as early ESB integration policies attempted to do,  or by ‘buying a BPM and business rules tool’, nor by ‘SOA’ing’ the organization, or offering ‘microservices’. These are all tools that can be used to achieve the goal of a new wave architecture but on their own they just add to the complexity of the wild west.

A key characteristic of this type of architecture is that of using out of the box (OOTB) or best of breed systems(BOB). When using OOTB or BOB solutions it is important to realize that you are buying these products because they perform specific functions in a way that is more cost effective than building that functionality yourself. With this in mind it makes little sense to try and re-engineer the functionality of these components once they have been purchased through heavy customization. Doing this will lead to a dilution of the cost benefit of buying these products vs building them yourself, and also lead to support and upgrade issues. As there are likely to be many such OOTB components in such an architecture gathering the true state of an enterprise at any one time can only be done in one of two ways:

  • Build a custom event driven ‘current state of the system’ data store. This is useful if you need up to the minute reporting
  • Service based information – essentially business services that gather and orchestrate information from the various OOTB or BOB systems and collate them. This is useful if you need fine grained information e.g. stock levels for a specific product.

Enterprise Architecture skills and direction are clearly required in this pattern.

Advantages

 

Description Notes
Can utilize best of breed systems Due to the ability to add new software components on a project by project basis we can closely align the IT landscape to the business requirements.  Capability catalogues are available to check for duplication and projects are governed by policies and rules.
Can develop bespoke systems If there is no good match capability in the market we can develop our own in house systems and create business advantage. Clear guidance is given as to when this is appropriate, and lists of capabilities of existing software is available to check we are not duplicating.
Not reliant on a single supplier/vendor We have a number of key suppliers, and the architecture is defined in such a way that they can be switched out quickly.
May offer better opportunities to scale As the architecture is designed for change we can swap out non-scalable components as required.
Can quickly change the system We can swap out parts of the IT landscape for components that better fit our new business requirements.
There is a clear an working process where new requirements can be identified and matched against capabilities quickly This means that teams are not tempted to produce short sighted point solutions.
Competitive advantage can be delivered through component selection, configuration, customization and development There is clear governance on when each of these is to be used.
Developers and SA’s can be well motivated and driven Developers can be focused not on efforts to fix elderly systems but on new developments that will bring real business value. Ideally development teams will be smaller but more focused on delivering software that will benefit the business, and also in a more timely manner.
Single source of the truth likely to be service driven not system focused. The drive to use COTS packages in this model implies that there will be data in many different sources, either due to system or domain constraints. Because of this up to the minute data is likely to be achieved through SOA type calls which orchestrate a number of calls to many systems or via a dedicated real time master data database.
Description Notes
Getting to this point is hard Once this architecture has been achieved, the benefits are clear. The route to this architecture can be difficult and can be subject to being cancelled. If this is done then the organization can be in a worse mess then at the start. This will hit confidence in EA and move us back toward our start point, or even worse back to a more complex wild west architecture.
The vision must be correct If the architectural vision is not correct then whilst we think we are moving towards a New Wave architecture we may in fact be moving towards a different monolithic or wild west.
Need to invest in EA skills and need to have clear Business strategy and vision You cannot do this in a half hearted way, the business needs to have a clear strategy and be sure why it will be successful and what it needs from IT. IT needs to understand this and develop a flexible solution which meets those requirements both now and in the future.
Mixed skill sets and new technologies It is apparent that in the majority of cases new skills and new software tools will have to be acquired. Software should be used primarily for its key design goals (e.g. use BPM for BPM, use ESB for ESB, use ECM for content management, do not think that you can or should use BPM as a cure all – beware of snake oil solutions!)
Cost There will be a significant amount of cost in investigation and analysis. This should be performed using a recognized framework, these are there for a reason, if you try and create your own you will miss key points to your analysis and these will cause you problems later. Learn from others mistakes.

2 thoughts on “Enterprise Architecture Types”

Leave a Reply

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