SOA Service Management (Part 1): Viewpoints of Complexity
By Anuj Sethi
I would like to begin by stating that the title above can be interpreted in multiple ways (yes it’s the word ‘Service’). Hopefully by the end of this blog you will be able to appreciate why I have stated so.
In most organisations the IT part has two sub-organisations: One responsible for design/develops the software (equivalent of a car manufacturing plant, at some level) and another which actually support the running software (equivalent of a car service station). The focus of this blog is on the latter.
IT Service Management (as defined by Wikipedia) is a ‘discipline of managing IT systems, philosophically centred on the customer's perspective of IT's contribution to the business’. So it’s a bit more than supporting client machines, servers, databases and network.
A key problem of 'Service Orientation' within IT (including the business part of IT) is bringing in is the explosion of terminology and acronyms. The main reasons of this are 1) vastness of this topic and 2) lack of standardisation.
Thus within the space of ITSM and now SOA Service Management there exist an endless list of new and existing terminologies which amplify the problem there by making it probably more complex than it actually is.
...'SOA Service Management', 'Runtime governance', 'Change time governance', 'Service Lifecycle Management', 'IT Service Management', 'ITIL', 'Production Support', 'Managed IT' , 'Infrastructure Management'....
I cover some points below which describe what is giving birth to this complexity/confusion in Service Management space with respect to SOA. Overall I believe some complexity is real, however some of it is perceived. It’s this way due to differences resulting from various viewpoints.
1) Understanding and Interpretation of the word 'Service' (in context of IT) is not consistent within and across the organisations. Thus at some point every IT organisation is required to define 'Service' in their context, one that gets well accepted within the organisation. Once this is done, the problem gets somewhat simplified.
2) Maturity of IT Service Management discipline. Although adoption of ITSM/ITIL disciplines is on the rise, not all organisation are in higher maturity state yet. It’s fair to state that an organization that has already employed an ITSM and ITIL implementation will have a much easier time defining and implementing runtime SOA governance and service management. Note the key benefit these frameworks provide is 'Governance' through policies and processes. This is building block for SOA service management.
To further complicate matters, nowadays there exist multiple frameworks to choose from and decide what & where to use and how they will work together. For e.g.: ITIL, COBIT, MOF, BS15000 ..etc
Well ITSM maturity posses the bigger question of overall maturity of IT Governance itself, but let’s not go digress there.
3) Proliferation of vendors in the IT estate. This one is quite obvious, if you have multiple vendors in the existing IT Management estate the complexity is probably already high. Every vendor has viewpoints on how their products are best used, thereby influencing the processes. Seamless integration and transparency are hurdles to cross in all dimensions of ITSM, i.e. Change Management, Release Management, Incident Management, Monitoring...etc.
Importantly we all are well aware that product vendors are always on the constant look out of means to sell new products, new versions of existing products. Thus new terminologies, acronyms are born as each vendor tries to differentiate and market the new shiny toys. (SOA momentum is helping them now than any time before.)
4) Operating model complexity. Another dimension of complexity is introduced due to the operating model of organisations. Typically a lot of IT Support / Infrastructure management is outsourced to multiple vendors under various contracts. Bringing these together into one way of operating/working is a gigantic task which goes beyond architecture/technology. Imagine, this would not be a problem if entire IT support across all architectural layers is outsourced to one single vendor.
5) Increased number of moving parts. I think this is sometimes exaggerated. "...very dynamic nature of SOA, many components, recombined for reuse.." Yes it’s true the number of parts will increase and their management will become critical. However if you look at existing IT service management, it deals with many moving parts even today. A critical application has at least following moving parts: middleware, web/application servers, runtime environments, database, operating systems, hardware, network etc.
6) Inconsistent understanding of SOA within the organisation. This is somewhat related to point#1, but with SOA adoption usually accompanied with concepts of Reusability - ‘lifecycle view of all assets’ and Agility – ‘iterative nature of processes’. This is quite a change from existing ways of working. Without adequate education and awareness within the overall IT organisation it’s difficult to pull people together towards the new way of working once it’s designed.
7) New architecture style so more complex management of running software. There exists a belief that SOA is new; so application/service management will be done completely differently and there will be huge impact on IT Support/Operate organisations.
I have a contrary opinion that existing IT Support organisation will find it easier to adopt SOA than the design/development organisation. Going back to Wikipedia definition of ITSM, IT support/management became ‘Service Oriented’ quite few years back and standardisation of same is on the rise. If anyone has had a look at ITIL v3, which is in existence for last 18 months, can appreciate this better. I will cover this more in my future blogs.
Lastly 8) Existing IT Architecture Maturity. If the existing IT application architecture state is making IT support/ITSM complex and inefficient, this will not improve by SOA adoption. Things will become more complex initially before reaching a managed state as the SOA adoption increases and standard processes are adopted.
In the next blog I plan to cover what are the best approaches to manage the complexity of service management in an end to end ‘Service Oriented’ environment.
Meanwhile, feel free agree or disagree with my thoughts and document your views about what adds complexity in this space.
A key problem of 'Service Orientation' within IT (including the business part of IT) is bringing in is the explosion of terminology and acronyms. The main reasons of this are 1) vastness of this topic and 2) lack of standardisation.
Thus within the space of ITSM and now SOA Service Management there exist an endless list of new and existing terminologies which amplify the problem there by making it probably more complex than it actually is.
...'SOA Service Management', 'Runtime governance', 'Change time governance', 'Service Lifecycle Management', 'IT Service Management', 'ITIL', 'Production Support', 'Managed IT' , 'Infrastructure Management'....
I cover some points below which describe what is giving birth to this complexity/confusion in Service Management space with respect to SOA. Overall I believe some complexity is real, however some of it is perceived. It’s this way due to differences resulting from various viewpoints.
1) Understanding and Interpretation of the word 'Service' (in context of IT) is not consistent within and across the organisations. Thus at some point every IT organisation is required to define 'Service' in their context, one that gets well accepted within the organisation. Once this is done, the problem gets somewhat simplified.
2) Maturity of IT Service Management discipline. Although adoption of ITSM/ITIL disciplines is on the rise, not all organisation are in higher maturity state yet. It’s fair to state that an organization that has already employed an ITSM and ITIL implementation will have a much easier time defining and implementing runtime SOA governance and service management. Note the key benefit these frameworks provide is 'Governance' through policies and processes. This is building block for SOA service management.
To further complicate matters, nowadays there exist multiple frameworks to choose from and decide what & where to use and how they will work together. For e.g.: ITIL, COBIT, MOF, BS15000 ..etc
Well ITSM maturity posses the bigger question of overall maturity of IT Governance itself, but let’s not go digress there.
3) Proliferation of vendors in the IT estate. This one is quite obvious, if you have multiple vendors in the existing IT Management estate the complexity is probably already high. Every vendor has viewpoints on how their products are best used, thereby influencing the processes. Seamless integration and transparency are hurdles to cross in all dimensions of ITSM, i.e. Change Management, Release Management, Incident Management, Monitoring...etc.
Importantly we all are well aware that product vendors are always on the constant look out of means to sell new products, new versions of existing products. Thus new terminologies, acronyms are born as each vendor tries to differentiate and market the new shiny toys. (SOA momentum is helping them now than any time before.)
4) Operating model complexity. Another dimension of complexity is introduced due to the operating model of organisations. Typically a lot of IT Support / Infrastructure management is outsourced to multiple vendors under various contracts. Bringing these together into one way of operating/working is a gigantic task which goes beyond architecture/technology. Imagine, this would not be a problem if entire IT support across all architectural layers is outsourced to one single vendor.
5) Increased number of moving parts. I think this is sometimes exaggerated. "...very dynamic nature of SOA, many components, recombined for reuse.." Yes it’s true the number of parts will increase and their management will become critical. However if you look at existing IT service management, it deals with many moving parts even today. A critical application has at least following moving parts: middleware, web/application servers, runtime environments, database, operating systems, hardware, network etc.
6) Inconsistent understanding of SOA within the organisation. This is somewhat related to point#1, but with SOA adoption usually accompanied with concepts of Reusability - ‘lifecycle view of all assets’ and Agility – ‘iterative nature of processes’. This is quite a change from existing ways of working. Without adequate education and awareness within the overall IT organisation it’s difficult to pull people together towards the new way of working once it’s designed.
7) New architecture style so more complex management of running software. There exists a belief that SOA is new; so application/service management will be done completely differently and there will be huge impact on IT Support/Operate organisations.
I have a contrary opinion that existing IT Support organisation will find it easier to adopt SOA than the design/development organisation. Going back to Wikipedia definition of ITSM, IT support/management became ‘Service Oriented’ quite few years back and standardisation of same is on the rise. If anyone has had a look at ITIL v3, which is in existence for last 18 months, can appreciate this better. I will cover this more in my future blogs.
Lastly 8) Existing IT Architecture Maturity. If the existing IT application architecture state is making IT support/ITSM complex and inefficient, this will not improve by SOA adoption. Things will become more complex initially before reaching a managed state as the SOA adoption increases and standard processes are adopted.
In the next blog I plan to cover what are the best approaches to manage the complexity of service management in an end to end ‘Service Oriented’ environment.
Meanwhile, feel free agree or disagree with my thoughts and document your views about what adds complexity in this space.
