Simple IT: SOA Done Right
In 1656 in his Lettres provinciales Pascal wrote:
I have only made this letter rather long because I have not had time to make it shorter.
The same applies to Architecture. Creation of a simple architecture typically requires more time than creation of a complex one. According to Steve Jones:
... I believe... the SIMPLE pictures that describe a business architecture are either not drawn at all or are abandoned because of their simplicity. People, architects especially, don't like putting in place the rigor and control that is required to deliver a simple solution, it’s much easier to deliver a blob and let people cope with it in support. Simplicity isn't a valued commodity because it doesn't allow people to show off their understanding of complexity.
So what constitutes a Simple IT? In his latest post Steve Jones defines it as:
... it comes down to a few key questions
- Can your IT estate be described as a series of discreet elements?
- Can each of these elements be easily maintained within their business context?
- Can each of these elements be simply described?
Explaining the meaning of these principles, Jones continues:
This comes down to that old principle of "one thing well", in IT this... mean... the building blocks of a simple IT strategy are not all of the same size, they are of the size that makes sense within the context of the business architecture... In a simple IT approach the focus is always on the on going evolution of the IT estate in line with business strategy and not based on a single project delivery.
According to Jones:
... the focus of simple IT is to value
- Long term evolution over short term expediency
- Architectural clarity over coding efficiency
- Business Strategy over IT strategy
Which comes very close to the definition of SOA:
SOA... [is] an architectural style promoting the concept of business-aligned enterprise service as the fundamental unit of designing, building and composing enterprise business solutions.
Summarizing his view on IT simplification, Jones writes:
The point here is that simple IT is not actually about making a single project faster, it’s about making the 2nd project and its support faster and more efficient. This means having control and direction into which the right approaches can be used... This is about having the business architecture, having the heatmap, and then aligning IT clearly into those areas.
Jones’ post emphasizes once again that SOA done right is not about technologies, like Web Services or ESB platform; it’s about using business-oriented decomposition for designing services. That is the only way to create IT systems representing enterprise business concepts, which allows driving IT costs in-line with their business value, creating clear traceability between business and IT and managing IT based on the different business value areas.
>> it’s about making the 2nd project and its support faster and more efficient.
This is no longer true. The role of architects and enterprise architects is rapidly evolving towards architecture refactoring. In a world where technologies come and go, grossly outlived by the solutions they support, they need to find ways to keep the solution running. Everything has become short term, there is no company small or large that will (truly) commit to supporting anything for more than 12 months. When a given solution is commonly relying on 10 to 50+ technologies, you get the picture.
Re: Simple what?
I think you are missing the point.
Of course technologies come and go, but underlying business services are fairly stable. The point here is if the business oriented decomposition is done correctly and each business-aligned service has a stable interface, then you are free to change any of underlying services with minimal impact to existing solutions, conversely you can introduce new solutions based on the existing services.
The simple IT is not about technologies, it's about proper decomposition.
Re: Simple what?
b) I don't know many organizations who got service versioning right, unless you understand that, there is no chance you can ever reach that state. Even if you do, as solutions become more and more composite, including 3rd party services (which don't typically offer any kind of versioning strategy), you are faced with a similar kind of problem but at the service level, in addition to the technology level.
So I am not sure there is a path towards 'simple IT' in terms of:
Long term evolution over short term expediency
Architectural clarity over coding efficiency
Business Strategy over IT strategy
SOA itself is no longer enough.