One reason I’m a fan of cloud computing, and in particular Platform as a Service (Paas), is that it restricts the design choices available when creating or integrating solutions. Of course choice is great but it can become a problem when there are too many options and no clear way to choose between them. How many times have you seen a project stuck in analysis paralysis? Enter the Architect…
Firstly, at the Enterprise level (and enterprise could refer to an entire organisation or an organisational division depending on structure and business model), there need to be some clear guidelines and technology selections. Exactly what these are will depend on what’s important to the organisation. Architecture principles translate what’s important to the organisation into guidance that can be applied to technology selection and solution designs. They will have the effect of restricting the number of choices available. Examples of restrictions include:
- High-level architectures: Monolithic, Layered, Service Oriented, Event Driven, etc.
- Data that must be common/shared (master data)
- Integration patterns (point-to-point, brokered, pub-sub, etc.)
- Availability targets, disaster recovery
- Security standards
- Data protection (e.g. how does the Patriot act impact ability to use cloud providers)
- Technology vendors
- Individual technology components like OS, Database, Middleware, Web
- Hosting: internal, virtualised, external
- Existing solutions/applications that will not be replaced
- Upgrade frequency (incremental or wait until support is ending)
I’d like to re-emphasis that, at the enterprise level, principles should only reflect the most important guidance and will lead to some restrictions in the list above. There will also be commercial considerations that bring restrictions, most probably due to enterprise-wide deals with vendors like Microsoft, Oracle and IBM to volume licence a range of products.
If the Enterprise Architecture job has been done well a reasonable number of choices will already have been made but there will usually be some still to make, for example:
- Do we make use of new features in the framework, database, server, etc.?
- Which library do we use for feature x? This is more of an issue for open source where multiple implementations are available as opposed to frameworks like .NET
- We could do this in compliance with the Enterprise Architecture but don’t have time and there is a non-compliant alternative
- This is a completely new requirement, where do we start?
I would suggest that if it’s taking a long time to choose between alternatives it is either because:
- The Enterprise-level guidance is not clear in this respect, in which case the Enterprise architect needs to be involved in order to clarify and update the existing guidanceor
- There isn’t a great deal to choose between the alternatives and there is deliberately no directive from the Enterprise level in this area (the project team is free to choose). My suggestion is to pick one or two, and try to develop a part of the most complex or disputed functionality (a spike test). The spike test needs to be quick, no more than a day or two: if it works stick with it and resist trying every alternative. In my experience it’s better to move a project forward even if some of the choices are later found to be suboptimal.