Service-Oriented Application Management

Samenvatting van volledige publicatie.

SOA and IT Management

SOA is sexy
Applications used to consist of several large programs that were difficult to modify and that were interconnected with batch-interfaces or by sharing data in common databases. These monolithic

the eighties and nineties were generally more modular and distributed and made use of graphical user interfaces and back-end database and application servers. SOA evolves the client/server

concept a step further but retains the proven design principles of loose-coupling and tight-binding.

The term ‘SOA’ was coined by Gartner in 1996 but it took ten years before serious (but smallscale) adoption occurred. The development of standards such as HTTP, URI, XML, SOAP and

WSDL played an important role in lowering the barrier. Adoption of SOA – if done well – results in the speeding up the realization and implementation of changes in the functionality. The development of the first SOA application for an organization will take as long – if not longer – than a non-SOA application. This is because of the investment in specific architectural and infrastructural facilities such as an Enterprise Service Bus and Service Registries/Repositories. The improvement will be noticed when developing other applications and when implementing changes. SOA can be used in order to connect applications with differing technologies. Unlocking the value of legacy applications is a very attractive prospect for many organizations.

This technology push is supplemented by a business pull from the user organization. Organizations experience the pressure of having to adapt rapidly to changing circumstances. This occurs for example in acquisitions and when their position in the supply chain occurs, especially when the supply chain partners have to exchange more information. SOA is promising and is therefore a ‘hot topic’.

IT Management is boring

In order to take a good look how service-oriented applications can be managed, it’s useful to realize how IT management has evolved. Fifty years ago we only talked about ‘computing’ or ‘EDP’, without a further breakdown in discipline X or Y. As Professor Maarten Looijen said, “everybody did everything”. Then our attention focused on systems development: since there were few systems, they had to be developed. Anything other than ‘development’ had no specific name, you just did it. Only later, in the eighties / nineties, we made a distinction between ‘application management’ and ‘infrastructure management’. Until this point the user organization didn’t have any role of importance but a few years later this changed and we started talking about ‘business information management’. This, in a nutshell, is the succession of paradigms which helped us understand IT management. Currently we use the subdivision in business information management, application management and infrastructure management, supported by process models such as BiSL, ASL and ITIL.

Management of SOA applications is risky

One of the foundations of IT management is having an overview of the components of a system that need to be monitored, changed etc. The functional design of a program is modified. Software

SOA changed lots of this. The application is now composed of components (services) that may be owned by the application management department and/or – and increasingly – by other departments or third parties. This alone is a new phenomenon for the application management department that is accustomed to have everything under its own control. Now there is a dependency on others, with which operational level agreements have to be made. And there are new types of artefacts to deal with, including:

Brokers that execute the actual invocation
So there’s plenty to do, but how to approach it?
Service Invocation, with special attention for the actual running of applications and invocation of associated services; ensuring adequate availability and performance

Recommendations

Adhocratic approach
As mentioned before, it’s wise to look back at where we’ve come from before taking a step ahead. We’ve often experienced the passage for one technology to another. What can we learn from this? The development of a each new technology follows an S-curve. At the beginning of the S-curve it is unclear exactly how to tackle the new technology but in the course of time the specialists get a grip on the matter and are able to formalise the processes, giving a feeling of ‘under control’. People who are competent in an established technology – for example in the mainframe domain – and are therefore at the end of their S-curve, look with stupefaction at how their (frequently younger, that’s the way it goes…) colleagues wrestle with the new technology.

We have encountered this phenomenon around the turn of the century, with the advent of internet applications. The regular IT departments were uninterested in – or scared by – a new technology that they regarded as a plaything so the business took the initiative and created special Internet teams outside the IT department. These teams were staffed by business-representatives, software specialists, network specialists etc, closely cooperating with each other in order to achieve a workable outcome. Bit by bit the process was formalised and in the course of time it was ‘promoted’ to normal IT, executed by the IT department. This multidisciplinary approach with highly knowledgeable specalists, unclear roles, intensive communication and informal coordination is known by Bennis, Tolfer, Mintzberg and Waterman as ‘adhocracy’.

When managing SOA-based applications, it is important to realize that we starting on a new Scurve, and that we should realise that we lack knowledge and that we therefore have to go through a learning curve before it the process can be formalised . An approach with a multidisciplinary team (centre of excellence, competence centre) currently seems the best approach to take.

In addition to this recommendation to adopt an adhocratic approach, investment in two other areas is strongly suggested: architecture and ownership.

Architecture

It may seem paradoxical, but a system that is based on extensive loose-coupling requires some form of central coordination. If not, you run the risk that the intended benefits of SOA will not be realized. Also, the failure of a SOA initiative will lead to a large divestment, not only financially but also in the reputation of the IT department.

Ownership

Another quote from the University of Amsterdam: “Regarding lager applications of SOA, there is some resistance and reluctance surrounding ownership of services.”

Conclusion

Application of SOA principles promises more flexibility, better integration and lower costs. However, the advent of such applications has implications for how application management. If SOA-based systems are not effectively managed, there is a considerable risk that the intended benefits – flexibility and integration – will not be achieved. The knock-on of this is that organisations will not be prepared to continue to invest in this technology, or that the investment will be spread out over a longer period, implying that the benefits will not be reaped as soon as they could be. Paying attention to the following areas – architecture, ownership and the manner of organization – can reduce these risks.

Architecture
More than with traditional applications, attention should be paid to the use of overarching architecture principles, otherwise there is a risk that the intended benefits of SOA will not be reaped. Also, the failure of a SOA initiative will lead to a large divestment, not only financially but also in the reputation of the IT department.

Ownership
A SOA-based system consists of various components, many of which are used by other systems and departments. This complicates governance and financing issues. The question of who decides about what should be settled in advance. Decision-making about and funding of common components should also be addressed.

Organisation
Finally – because management of SOA-based applications is currently immature and therefore still difficult to formalise – it is prudent to management such systems in an ‘adhocratic’ way (multidisciplinary team with high skilled specialists, intensive communication and informal procedures). Once best practices have been created, the processes can be formalised and it can be ‘promoted’ to normal IT in the regular IT department.

Author
Mark Smalley is specialised in Application Management and works as Principal Consultant for Getronics PinkRoccade, also representing the ASL BiSL Foundation in international affairs.

Reading list
M. Looijen, in ICT Pocketbook, Reed Business Information, 2007, pages 383-389.
Key Issues for SOA, EDA and WOA, Gartner, 2008
Introduction to Service-Oriented Architecture, Gartner, 2003
Migration of Legacy Assets to SOA Environments, Carnegie Mellon Software Engineering
Institute, 2006
SOA Trend Survey, InfoWorld, 2006
SOA in Nederland – a digital disease?, University of Amsterdam, 2007

Application management was initially pretty operational and reactive. About fifteen years ago, in response to the higher


-- Printbare PDF-versie --


Auteur: Mark Smalley op 24 februari 2011
Categorie: Analyses, Oplossingen, White papers
Tags:, , ,
Licentie: Public Domain

Checklisten:
Organisatie informatievoorziening 13 vragen.
Selectie te gebruiken methodologie 38 vragen.
Criteria bij decentralisatie 18 vragen.

Geef een aanvulling

Je moet ingelogd zijn om een aanvulling te geven.

Laatste artikelen