Showing posts with label ITIL. Show all posts
Showing posts with label ITIL. Show all posts

Saturday, January 2, 2010

ITIL Services

ITIL Services are different from Services Oriented Architecture (SOA) Services. The Information Technology Infrastructure Library (ITIL) is an accepted standard for operational IT issues such as incident management, problem management and change management. ITIL builds up a large set of terms and tries to use these terms consistently throughout its discussion of Service Management.

The conflict over the term "service" can lead to some confusing conversations between developers and operations staff. I have posted earlier on the definition of services in SOA. The ITIL definition is
"A service is a means of delivering value to customers by facilitating outcomes
customers want to achieve without the ownership of specific cost and risks. "
ITSMWatch

Two very different examples of a service in ITIL could be a payroll system and the resetting of a LAN password. The services of an IT organization should be available on a "service catalogue" and the clients of the IT organization can use this catalogue to choose and understand the services they receive.

This is different from an SOA service. An SOA service is a software component which:
• Hides its implementation,
• Is based on standards,
• Is location transparent,
• Is message coupled, and
• Is accessible through defined platform independent interfaces.

The main difference is that an SOA service is a software component in SOA. It is not the service that a help desk provides when they reset your password and it is generally smaller than a whole payroll system. An SOA service can be hidden away from the users in the cloud of application components. Ideally it is granular enough to have meaning to users but a user does not need to be able to interface with a service directly.

There can be coincidental overlap between an SOA service and an ITIL service. A service for paying a bill may also be presented directly to the users of an IT Department or organization and therefore be a service on their catalogue. This only seems to confound the issue. It is safer to assume that ITIL stalwarts and SOA engineers are talking about different things when they refer to a service.

IT Service Management (ITSM) under ITIL however can provide an appropriate means for providing governance for your SOA and for providing the operational platform for your SOA. SOA may contain more component parts than traditional systems and a disciplined approach to configuring, operating and changing these parts is required which is exactly what ITIL offers.

Interestingly ITIL also seems to redefine SOA as "Service Offerings and Agreements" and "Service Outage Analysis" which also makes life complicated.

Notes:
Some good articles on ITIL and SOA follow:
http://www.ca.com/Files/WhitePapers/soa_wp_jlong_33146.pdf
http://www.ibm.com/developerworks/ibm/library/ar-soaitil/
http://www.ebizq.net/blogs/bethgb/2009/03/can_itil_help_fix_soa.php
http://www.biske.com/blog/?p=467

The book I am reading which proffered the payroll as a service example is:

Klosterboer, Larry, 'Implementing ITIL Change and Release Management', IBM Press, 01 Dec 2008.

Saturday, February 23, 2008

The Importance of Meta-Projects

The feature video on International Association of Software Architects (IASA) site last week provided. I wish I could reference the speaker and the name of the video but alas last weeks feature video has been replaced by this weeks feature video.

The talk was reasonably pragmatic discussion of Architecture by a staff member of delta airlines. What inspired me to write this posting was that a slide that depicted "Business Enablements" things, like agility and collaboration. It also depicted lists for Business strategy and IT strategy. This is nothing new but it reminded me I need to lift my eyes from the day to day IT projects and see what my organisation is doing for software development as a whole.

This is timely because its time for my branch to put together a plan for next year. Typically this has been very project-focussed. Of course I also hope to put together a good graphic although I doubt whether I can do as well as the delta-airlines chart.

Each business and each IT department has its projects to achieve some outcome for the business. My focus is on application development projects. Often these projects are part of a bigger business project and commonly involve business process changes and infrastructure changes. Another category of projects do not achieve direct outcomes for the business but allow the business or the IT department to undertake these projects in a more effective manner. For business projects these 'meta-projects' is what was referred to as "business enablements" by the IASA speaker. I will not be using the term further as my spell checker says "enablements" is not a real word, and I tend to agree.

To put these in context see the following table

BusinessIT
Goals/ObjectivesBusiness Goals. Mission, Vision and StrategyIT Strategy
Meta-ProjectsBusiness meta-projectsIT meta-projects
ProjectsBusiness projectsIT projects

There are strong relationships between each cell in the table and its neighbouring cells. The business goals drive the IT strategy and also the business meta-projects. Business meta-projects may drive business projects but also meta-projects may be driven by projects. Neither the meta-project or project is necessarily the driver. This is the same with IT meta-projects and IT projects. IT strategy should drive the IT meta-projects and IT projects.

The IT Meta-Projects that my IT department is engaged in are:
  • SOA
  • Enterprise Architecture
  • Mobility (Supporting mobile computing devices)
  • Business Intelligence (Data Warehouse and Reporting)
  • Legacy Transition
  • Spatial Systems (Geographic Information Systems)
  • Online Project (Customer-facing IT systems)
  • Identity Management (Authentication/Privileges/Access Control)
  • Service Management (ITIL, Request Management, Change Management)
  • Performance Management (Individual Performance)
  • Cost Efficiency/Consolidation (ongoing)
  • Business Alignment (ongoing)

Some of these meta-projects have explicit planning documents explaining the plan. Others are more just acknowledged as the agreed direction of the IT department. Cost efficiency and business alignment are not specific projects but an ongoing focus of attention as they would be in most IT departments.

Some of these IT meta-projects such as Online Project, Service Management, Performance Management and Costs Efficiency have analogous business meta-projects. Business Alignment parallels the business meta-project of customer alignment.

This list of IT meta-projects has not previously been written out. It is surprisingly long, especially given the much longer list of specific software development projects that are on our books. Ideally each of these meta-projects should be explicitly planned, prioritised and monitored.

Meta-projects provide a foundation to the work an IT department does. They could also be referred to as 'foundation projects' but they are not necessarily just internal projects as they may be programs of projects that directly affect the business user. The meta-projects help build the look and the feel of the IT department. They establish its competitive advantage and its identity. Accordingly, it is important to get these meta-projects right and to provide them with the attention they deserve over the more day to day concerns of getting software out the door.

Friday, October 5, 2007

Conference Summary Served with Spaghetti

I presented at a conference “Achieving Interoperability in Systems Architecture” on Wednesday. The occasional get together of architects, managers and developers is valuable. You can grab the odd new insight and find new approaches but it is also good to see others attacking problems in the same way and validating your own approaches.

After the conference I thought I would finish this summary on the aeroplane home. I have always wondered how to spend the time on long flights profitably and I admired a couple of passengers using laptops on my previous flight. Unfortunately as I try to use the laptop in flight I am in a middle seat with no elbow room on either side, and now I am served dinner in middle of the flight. I am juggling my laptop and the worst Spaghetti Bolognaise I have ever tasted. Still, here is the summary.

Josh Graham of Thoughtworks kept time well and came up with the comment “Why should I expect straight lines on my Business Process Model when business is inherently messy.” He also introduced one of our New Zealand guests as coming from the land of the “Wrong White Crowd” which sounds like a political comment and spoonerism wrapped up into one.

Mark Murphy of Tower Aust Ltd advocated we start small with SOA. He quoted IDC showing growth in SOA from $3.5bn in 2005 to $33bn estimated in 2010. Mark looked at some SOA definitions and aptly described the current situation where people build silo applications and then expect IT to join them together. He showed a couple of models from Sun and Microsoft showing SOA models that illustrated logical SOA.

Stephen Smith of Arcbok presented a simple framework for assessing the readiness of an organization for SOA. The framework consisted of assessing an organization on the dimensions of Leadership & Culture, Business, Technology, Knowledge, Funding and Sustainability. Each dimension has a number of questions to ask about an organization to asses its readiness. The sustainability dimension described whether the organization had the appropriate support, operations and governance in place for sustain the SOA. This also could include appropriate operational monitoring, measuring and standards. A readiness assessment tool is about risk management. Beware vendor maturity assessments that are used as tools to sell more services.

Krist Davood of AGL and Sensis has achieved something that everyone in the room envied. He had success justified SOA as an initiative using fairly hard-nosed accounting principles. He had justified SOA because of its ability to avoid periodic failures in the business because of the current way of doing things. He had been able cost these failures and justify the project to introduce SOA into the organization. SOA as a strategy to eliminate risk had been demonstrated to be effective.

Centrelink is a huge SOA operation and it was good to hear from Rob Doughty who is their Applications Architect. I liked his characterization of users as “Human Task Delegates” in relation to workflow applications. It was interesting for me to hear about the legacy system challenges that Centrelink have, but also how their portal work in benefiting other government departments. The focus of the talk was the deployment of a portal product which they will be basing all their systems on. I liked the comment that “Portals bring people and process together”. Rob talked about the challenge of working with various IT groups to deliver on a particular pattern of use in relation to the portal. He advocated the use of an “Integration Competency Centre”.

I then presented on Enterprise Architecture and its links to metadata and SOA. Some of this material is already on my posting on SOA Definitions, SOA Metadata and the Zachman Framework. I will elaborate in a future posting.

John Fisher from the NZ Ministry of Education showed us some great business modelling techniques that had found favour with his users. The technique involved Business Element Models, Business Component Models, Business Role Responsibilities and Business Service Models. The models were focussed on producing requirements for widely federated (eg. For 2,700 schools) SOA systems. He introduced the analogy of using power adapter so could use a drill brought in the UK to explain SOA to users.

Jan McConchie of SA Government ICT Services provided an overview of the challenges that she has to bring together the South Australian Government Services to present a common face to the South Australian citizen. This was interesting because the SA Government has established and Office of the CIO and this is showing the desire to coordinate and rationalise government IT activities. As one of the agencies involved, my organisation will be affected by standardisation and IT governance changes. Jan drew on research by Gartner and Saugutuck Technology to explain what SOA meant to her and discussed some initiatives in place for the SA Government.

Chris Howard was from the State Revenue Office of Victoria. Chris focused on risk and SOA and quoted Gartner, advising that it would take 3-4 years before investments in SOA payed off. He discussed a long term plan for legacy transition which was underpinned by full and frank statements about costs, benefits and risks with his business. Chris endorsed ITIL as an enabler of SOA.

Josh ran an interactive session where we discussed the issues of SOA and getting the business on board. It was never clear what you will find when you "turn over rocks" in the analysis process. We discussed what services to build first. It was not always best to do the low risk, high value project first. In the end it might just be business or legislative imperatives that help you make the decision. It was difficult to decide when to do those cross-cutting "hygiene" services.

George Cascales from Integral Energy discussed how he was implementing SOA in an out-sourced environment. He had a small group of architects and had succeeded in being able to develop new applications quickly using reused services. His group focused on standards and governance rather than the actual development. A set of tools and standards would be given to contract developers to develop the services and applications.

Rajat Chopra, the international speaker from Bell Canada provided a good description of how Bell embraced SOA. It was important for Bell to provide common services to serve its various customer channels for selling telecommunication facilities. Rajat provided us with a number of analogies for explaining SOA to management including Lego blocks, a car factory and diet. With diets, you can latch onto gimmicks but in the end it is lifestyle change that makes the difference. This is the same with SOA.

Alex Jouravlev representing the ACS presented twice. Alex’s first presentation was titled Prepare IT and Business for SOA. He traces the origins of SOA back to 1988. He made the point that our business cases do not really engage the business and we need to strive for simple messages using language the business understands to achieve a ‘mental ownership’. Alex supported the model driven architecture approaches but not for the reasons that they were developed. Business requirements should be developed with referencing any ‘system’ and should be modelled with Visual UML Models. Alex noted that several modelling practices that were usually acknowledged as important were often missed. These include Conceptual Business Modelling, Conceptual Data Modelling, Business Object Modelling and producing an Enterprise Ontology.

Later in the day Alex was able to present a model based on CMMI maturity model in an easy-to-understand fashion with the purpose of moving the SOA objective from IT to the business as an organisation obtains more SOA maturity. Alex was able to give us a realistic view of the limitations that would be expected at each level of maturity and provide an insight into how the role of key players like the Enterprise Architect and Business Analyst would change at the various levels.

Ram Kumar was from OASIS and provided an insight into the work of this organisation that is emersed in creating SOA standards. He discussed his role in developing the Justice Sector Information Interchange standard. This was of special interest to me because of my involvement in this sector. Ram emphasised the importance of XML governance and advocated this for successful SOA.

Josh summarised the conference and he may discuss this on his own blog site. Many themes resonated with me but one stands out as I wrestle with my in-flight dinner. We had slides from at least three of the speakers that showed insanely complicated maps of their existing systems. It seems we are all lumbered with integration spaghetti and our hope is that SOA will resolve this.