Complex Landscapes

I have spent the last few weeks reviewing some application management support deals. It seems to me that business is being driven by short term goals rather than long term – and that approach is costing them dearly in the long term, both in terms of flexibility and money.

When a customer buys a hardware solution, one of the major criteria for the choice is the total cost of ownership – it will be cheaper, more economical, or whatever to run it on the latest, fastest more efficient chipset. However it seems when it comes to applications, speed to deploy and cost to deploy are the main considerations. Businesses look at the total cost of acquisition rather than the total cost of ownership.

Surely the quicker and cheaper to deploy is the best in any case? Well normally not. Ill thought out solutions often increase the complexity of your estate rather than reducing it. Ultimately this will end up costing you more in terms of money and flexibility. Let’s take a simple example of a partial Service Orientated Architecture (SOA) implementation that would wrap, rather than re-engineer, the legacy system to expose it’s offerings as services to the rest of the estate. It certainly makes it easier to interface to the legacy system, but at what cost? The solution has solved something by adding another layer (or more) into your estate. You will still have to run the legacy system, still have to it to maintain, you will also have to maintain the new SOA services. Your estate has become more complex.

I am not stating that SOA is a bad thing, it is just an example. There might be good reasons for doing the example I gave above. Perhaps it allows you to isolate the legacy system while you develop a suitable replacement - so that it is easier to replace, in which case this will make that transition easier. This would be a good use of the service – as a means of transitioning. However this is not the normal case in our world. Solutions are performed piecemeal with little long term strategy – what will be introduced as a strategy will be overturned in coming years when that money is required on even more functionality.

So we continue to make our estates harder and more difficult to maintain we increase the complexity of our estates, and we do it often by adding layers of technology which it is ‘supposed’ to make it simpler. In fact it does the opposite.

So what is the solution? Well it is reasonably obvious, we need to stop trying to hide things that are difficult to understand behind a curtain and get to understand them. It is odd that in no other field of business would a businessman say that area is too complex to understand – I’ll just ignore it! Yet the business – IT gap makes that seem acceptable and normal.

The bottom line is simple, just like one of the Brownfield beliefs – embrace complexity rather than ignoring it.

Do this and your world will become simpler.

Where are the requirements hiding?

I've just been on a architecture Masterclass - which was nice. Unfortunately the class did little to dissuade the attendees that the IT industry has more than two types of requirement. It stuck to the line that we basically have functional requirements and non-functional requirements.
The Functional requirements are probably the best known. They tell the designer what the system has to do, usually from the perspective of the end user. Nearly everybody agrees these days that Use Cases are a pretty good way of capturing these requirements. I’ve used some alternative more technical approaches on some big projects, but we’ve nearly always had to create use case like perspectives anyway, just so we can communicate to back to the users. If you can get away with agile Joint Application Development techniques where the users and developers sit down together in small grounds then you’ll probably do even better, but often the high burden of detail, testing and sheer size of the projects we deal with means that such an approach gets ruled out.
The second form of requirement – the non-functional requirement are rather more poorly treated by tooling and there are few widely accepted good practices. The non-functionals tell the designer what the characteristics of the solution should be. Not what it has to do, but how it has to do it. The system must be always available. The system must provide sub-second response times 100% of the time. These are just two of the often impossible and conflicting sets of requirements that we deal with as lead architects.
NFRs are the requirements that make designers proud. You’ll rarely hear them boast that the system they created had the best implementation of a “Find Customer” Use Case, but they’ll never stop crowing that it could support 80,000 concurrent users whilst enabling a full recovery from a plane landing on the data centre within fifteen seconds without the loss of any data…
The odd thing is, the more projects I do, the more I am convinced that we miss most of the requirements that we actually need to deal with. They don’t fit into the functional or non-functional space. They are called constraints. Constraints outnumber the other requirements 10:1. They are all those Entreprise Architecture standards you need to conform to, they are the existing data you need to migrate, they are the interfaces to the existing systems, they are the budget, they are the timeframe. Basically they are the difference between the system working in its environment and context, or not. They are the Brownfield aspects of requirement. The NFRs and Use Cases talk about the system as if it lived on its own little planet. They define the boundaries and shape of an isolated bubble. What they conveniently ignore are all the provisos that actually make the system hard to deliver. It’s here that we see implementation projects fail: they adopt a domain model which is incompatible with the rest of the organisation and make integration impossible; they ignore the real complexity of the interfaces with other systems, assuming that an interface is just the definition of a data structure, they ignore the fact that the data used in the system is now duplicated in multiple places.
What’s worse is that these things are often found out late in the project lifecycle resulting in unexpected expense and delays. Why don’t we just accept the fact that systems have to be deployed into complex environments and do what any respecting building architect would do: commission a Site Survey and use its constraints to influence the design? It’s the Brownfield way, you know its right.