Wild West Architecture
This architecture is typified by multiple systems integrated together using one or more integration methodologies. This architecture covers most of the architectures we see in enterprises today as their IT infrastructure matures. Often in this architecture we see overlap of IT technology capabilities caused by numerous factors, and we can also see repeated attempts to ‘simplify’ or ‘control’ the IT landscape as it becomes cleat that it is becoming too difficult to control.
Drivers for this architecture include the need to implement and change quickly being restricted by the flexibility of existing systems, new ideas being brought in by new key hires, new business requirements e.g. corporate content management, API management etc.
The key identifiers for Enterprise Architects that an organization is in this state would include some but not all of the following:
- many diverse systems interconnected with point to point systems
- possible evidence of one or more enterprise strategies that have stopped but have complicated the landscape as they have been terminated before completion
- Very strong SA input into projects and very low overall vision to give guidance
- A focus on solving todays problems regardless of the past (re-inventing things that have gone before as they have not worked as planned – little reuse)
- Reliance on SA integration patterns e.g. Queues, FTP, Point to point etc.
In this environment EA’s should be strong but they tend not to be. This is generally due to a lack of confidence in the value that the EA team would bring into the organization as it is perceived that we can just continue to add to the spaghetti and we will somehow simplify everything. You may also see one or more key SA’s taking the lead and trying to simplify or significantly re-engineer large parts of the IT landscape in a unilateral manner, likewise if there is a monopolistic architecture historically in place you may find embedded SA’s that insist that software should be used for everything.
This architecture is present in most medium to large organizations but specifically those that:
- are focused on the here and now and do not have clear long term IT or business strategies
- have been burnt previously by enterprise solutions or programs that have not been a good fit
- organizations that are focused on immediate return for IT investment
- typically in these organizations SA’s are 100% project based and have no time to sit back and plan a strategy.
| 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. |
| 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. |
| Not reliant on a single supplier/vendor | We have a number of suppliers in the mix so there is a belief we can change suppliers and switch out capabilities as required. |
| May offer better opportunities to scale | If certain parts of the landscape are not scaling with the business then we can replace those areas with new components that will scale. |
| Can quickly change the system | We can swap out parts of the IT landscape for components that better fit our new business requirements. |
| Organizational units can and will introduce point solutions. | This solves immediate business issues, and is done unilaterally. This is often an indicator that IT architecture is failing to keep up with the need for business change. Without EA involvement this often leads to short term decision making. |
| Competitive advantage can be delivered through component selection, configuration, customization and development | Often there is little guidance as to when these should be used and therefore we often see bespoke development being used too frequently. |
| Developers and SA’s can be well motivated and driven | You often see a mix of some highly motivated IT staff ‘we can solve all the problems one piece at a time’ and some more lethargic ‘we have seen it all before – it will fail’ it staff. |
Disadvantages
| Description | Notes |
| Multiple Technologies | This will require multiple skill sets to maintain, not only with third party tools but also with key bespoke development tools, we can attempt to control this with insistence on a key technology such as .NET or Java. |
| Complex architecture | It is very often the case that no-one knows what is connected to what else. Although there are enclaves of knowledge the big picture is too complicated. This leads to change paralysis as you cannot change one system without knowing the impact on other capabilities. Documentation is often out of date[2] and there is a strong reliance on the knowledge of key staff members. |
| Upgrading is complex | Due to the side unknown side effects upgrading components within the architecture is complex and often fails due to foreseen interactions. |
| Backup/failover | Due to the mix of systems synchronizing backups across the landscape is incredibly complex. |
| Cost of change environments | We need to duplicate the complexity of the production environment in Dev/Test/Staging to try and ensure that risk during deployment is minimized. |
| Change impact | The impact of projects must be risk assessed, however due to the lack of documentation this is usually impossible. |
| License Cost | As there are multiple vendors and overlapping capabilities the cost of licensing becomes high e.g. if you are using two BPM tools across the business you will have users licensed for both. |
| Changes begin to slow | In the initial stages of these architectures changes are speedy, but as complexity grows the speed of possible change will slow dramatically. |
| Information Availability | As there are may systems with similar or duplicated information, which tends to be access in an unstructured fashion, there is often real trouble finding accurate and up to the minute corporate information such as current stock levels. |
Nice information about types of enterprise architecture.
Great understanding of the positives and negatives regarding the architecture work. Really helped a lot. It has improved my knowledge.