One of the most common tasks of IT departments is to move information between different roles in the enterprise and to enable them to view and manipulate the information as well as get insights out of them. Each one of those roles wants the data to be moved using a different vehicle, but dose this mean that you need to create a different solution for each role. Each one of those roles wants to change the vehicle when his environment changed to be able to better work in his new environment. Are you building him a new SUV instead of the previous Hammer that he used?
I’m not using the car metaphor just for fun, the car industry managed to come up with architecture that enables them to create different types of car but based on the same chassis. Are we as enterprise architect doing the same?
When you hear the term application infrastructure you probably think of software infrastructure like databases, GIS software, visualization tools and other technology and hardware infrastructure that usually support our applications those days. But, are just technologies and commercial software can create your application infrastructure?
If your enterprise decide to be based on SOA as leading architecture style and your implementation is based on your enterprise business capabilities, you probably can take your IT infrastructure into new heights. Creating collection of services that reflect the business capabilities actually create new IT infrastructure, a business Infrastructure that enables IT to create different bodies based on one IT chassis. This application platform together with the traditional infrastructure (that I just mentioned) is the IT chassis that you can based your IT vehicles on.
Building such IT chassis enable you to create different bodies on top of the chassis and eventually reach much more reuse and flexibility. Those bodies are workflows that we build in order to serve our clients needs.
Using SOA to create services infrastructure is not so obvious. To build such infrastructure there are two main points that you better think of:
- A model that describe what types of services (granularity level) needed, how they related to business capabilities, how they compose business processes, what their relation to the enterprise information model and what the software components that exposed them needed to be define.
- The traditional way of building software needed to be changed. Production of services needed to be separate from production of workflows that uses services. If the development of the chassis is being done by the same team that develop the body you’ll fond that application aspects were implemented inside the chassis. The result is a chassis that is less generic and will support fewer bodies.
