The health and well-being, and today the very survival, of an enterprise depend on its ability to respond and adapt in timely, innovative, and effective manners. The relatively static behaviors of the past have been changed unalterably by the explosion of telecommunication and information technologies/capabilities as typified through the emergence of the World-Wide Web (W3). Enterprises are learning to adapt to the challenges of the new global business and national security environment by exploiting the same capabilities that are driving the dynamic environment, telecommunications and IT. In essence, information and the knowledge derived therefrom have emerged as key assets of the enterprise in responding and adapting to the demands of the global environment.

The experiences over the past decade for a wide variety of enterprises, including both governmental and commercial entities, are reflected by more failures than successes in embracing successful strategies and solutions for creating, engineering, and evolving the knowledge system that serves the enterprise most effectively. Certainly, problems have arisen through failures of leadership and management, who have been unable to break the static behaviors and narrow organizational views that served them well in the past. On the other hand, engineers, given responsibility for exploiting information technologies to meet the information needs of leadership and management for knowledgeable decision making, have found the challenges of dealing with the complex event-driven environments and the complex array of enterprise stakeholders and systems vastly more difficult than the systems engineering problems of the past.

Why this book? – Because it is a book begging to be written. The real world is chaotic and never stands still. Businesses constantly strive to re-invent themselves under continual, and often intense, pressures of competitive, regulatory, and technological change. The pivotal issue in business computing lies in incorporating new learning in automated information systems; adding to what is already known and adapting automatically as perspectives and priorities continually change. This is the challenge for which we have sought the answers presented in this book.

Where did it all start? It was 1992. One of the authors was the Chief Methodologist for the American International Group, an unusual global corporation that believed in turning on a dime. The firm needed a systems development discipline to facilitate nimble and innovative business practices. Thus a truly exciting and wonderful journey began – a journey we want to share with you. In this book, you will find readily usable patterns and models you can leverage to establish business requirements, object models, and knowledge bases to support the agile and exacting business needs of the twenty-first century. You will also find the exciting and simple beauty of a framework that is the direct bridge between business process engineering and systems engineering. Yes, it is a proven framework that works for every industry and business application we have tested it on – from telecommunications to insurance, from financial services to manufacturing.

An attribute is a special kind of object. It is the repository of an irreducible fact that a specific rule or property of an object class exists.

Every object must have at least one attribute – the instance identifier that asserts that the object itself exists. This instance identifier must always be a nominally scaled attribute because it asserts a nominal irreducible fact – the existence of an object instance – whereas other properties of object may map to nominal, ordinal, difference, or ratio scaled domains.

The structure of attributes and states

Every attribute has three items of information associated with it – the object it describes, the kind of property it represents, and its value. The value is the actual property the object instance possesses. For example, length is a kind of property and the length of a room is an attribute of an object class called room. The fact that a room is 20 feet long asserts the (value of) length of a specific room, i.e. an instance of room.

Gleaning early value

As mentioned earlier in chapter 2, the first moves toward service orientation are likely to involve stepwise tactical exposure of legacy systems to glean early business value. Recall the approach described in our service-oriented process redesign pattern:

• Scope process redesigns, with measurable goals, in line with SOV7

• Redesign the processes focusing on using existing assets or external services

• Plan and implement incremental process improvements.

We begin by focusing on process redesigns likely to yield “quick wins” with minimal effort, pinpointing legacy functionality that can be offered as software services to the redesigned process. Our main focus in this chapter will be on business process models, as depicted in relation to the BA in figure 5.1. In early iterations it is unlikely that much time, if any, will be spent on the three underpinning activities of the pattern, aimed at achieving long-term business agility:

• Establish service policy in relation to business goals

• Understand domains and identify services and their dependencies

• Survey and catalog assets.

However as time progresses so these longer-term activities (described in chapter 6) will come increasingly into play.

In this chapter we shall provide a simple example of tactical first steps in moving toward service orientation based on incremental business process redesign given an existing legacy portfolio. We also consider the concept of SOV7 in more detail, and show how to apply it to achieve a better business process redesign.

Part 5 of this book provides two case studies in service orientation.

In chapter 14, Sam Higgins and Paul McRae describe how Queensland Transport has developed a service-oriented approach that reflects service orientation as the business phenomenon described in this book. In particular, they look at how the approach is used to allow third-party software developers to integrate Queensland Transport regulatory processes seamlessly within commercial motor vehicle dealer business processes. The results are impressive. For example, the organization can now execute a service-based transaction at an activity-based cost of less than A$1.5 compared with the more traditional face-to-face approach which costs between A$4 and A$10. The department now collects over A$260 million (or 12%) of its total revenue using an SOA, with no direct customer contact. Services are available 23.5 hours per day, 6.5 days per week, and 80% of all services respond in less than 2 seconds.

In chapter 15, Hermann Schlamann describes how Credit Suisse has evolved from an organization encumbered by a large and complex legacy software portfolio to one which can now use significant parts of its legacy systems for business value. The organization has worked hard to rationalize these legacy systems into sets of reusable services that are aligned with business objectives. Again, the results are impressive. For example, money transfers for a customer are now enabled over different channels: via the internet with “online banking”, via a “teller terminal” in a branch, or via “personal contact” at a branch counter.

Specification before process

There are a host of cultural factors affecting the uptake of service orientation. Many detailed processes are possible. In this book, we have emphasized a lightweight approach to process, introducing process patterns to assist where useful. Our main emphasis, however, has been firmly on deliverables. The view is that if you get the deliverables right then processes will usually follow.

At the same time, cultural change is a lot more than instituting the right processes. Above all, it is about getting the best out of the organization's people and about the market in which the organization chooses to operate. In this chapter, therefore, we resist the temptation to add to the groundswell of procedural guidance – the fact is that organizations evolve and adapt their processes to fit their people and their market. Our focus is on offering guidance on the roles that are required for individuals to play in relation to service orientation, and on sketching some scenarios that depict different market contexts that organizations may find themselves in. Armed with clear guidance on specification, along with role definitions and market guidance, the organization can adapt their processes to maximum advantage.

Supply, manage, and consume

What I first referred to as a “two-tier” process in relation to CBD (Allen and Frost, pp. 12–14, 1998) continues to be relevant to service orientation. This is a model that I further enhanced in relation to e-business in the form of a “track-based pattern” (Allen 2000, pp. 50–2).

Management of services is commonly treated as an entirely separate subject from topics such as business improvement, business process redesign, software architecture, and software development. Worse still, both the management of run-time software and the management of SLAs, are traditionally dealt with as separate IT concerns that have little to do with each other.

In part 4 we examine the imperative for this situation to change and introduce a new discipline, SOM, to bring together the areas of SEM, SLAs, and SLM in a cohesive fashion. We show how this approach integrates with both SOA and BA to round off an effective execution strategy for service orientation.

Chapter 11 paints the “big picture” of SOM. We explore the major gear shifts that are required to move from traditional management of software operations to execution management of software services. In particular, we explore the connection points between the various disciplines and examine their relationship to ITIL.

Chapter 12 describes a streamlined yet rigorous approach to the key topic of SLAs that is in tune with the ITIL guidelines on service support and delivery. We set out an approach that is integrated with both BA and SOA, and that is designed to cater as easily as possible for the migration of business processes toward composition from services.

A stepwise approach

The great majority of organizations are not in a situation where they have the luxury of designing their processes from scratch. These companies must adjust and develop their existing processes to meet the challenges of service orientation described in chapter 3. For example, with a service-oriented approach, the emphasis is much less on decomposition and value chain flow, much more on collaboration and reuse of business capability.

In addition, the business models of these organizations, whether explicitly stated in the form of a business process model or whether implicit in the way the company operates, are dominated by the notion of the end-to-end value chain. However, it is unrealistic to expect that these business models and modes of operation can be replaced overnight. As we have repeatedly said, service orientation is much more a matter of evolution of best practices.

For all but a few companies, able to start out with brand new business models, the need is for stepwise process redesign. The need here is for delivering “quick wins” that increase return on investment in terms of increased business value or reduced business costs. At the same time, the idea is to evolve a set of services which are offered to the processes, as part of the longer-term goal of business agility. This evolutionary approach is a keynote of both our case studies: Queensland Transport (detailed in chapter 14) and Credit Suisse (detailed in chapter 15). So a balance is needed.

Web services in context

Your early attempts at service orientation are likely to be within the organization firewall, aimed at low-risk demonstrations of business capability, and involve modest numbers of users. These early solutions may well expose legacy systems in the form of software services, but without great heed to the scalability of these services. If successful, there will soon be pressure to scale up those early solutions to cater for mission critical functionality over larger groups of users. It is Web services that provide the group of emerging technology standards necessary to industrialize your services. There is a core group of established Web services standards that are required to climb the first rung of the adoption ladder. Other emerging Web services standards are required to progress further.

At the same time, as transactions grow larger and more frequent, their execution must be carefully monitored and controlled, in line with the specification of the service. Security becomes an ever-increasing concern, too, as we saw in chapter 1, as the company extends its reach beyond the firewall to more and more external users and partners. While Web services standards are necessary to deal with these issues, good execution management becomes increasingly important as your organization moves upward through the technology adoption curve, across increasingly complex distributed networks.

“Yes,” we hear top management say, “but if this stuff needs to be ramped up we'll just outsource it to the experts.

Why this book?

We live in a world of change. During my thirty-plus years in the software industry, I have witnessed some remarkable changes. One constant, however, seems to me to be that successful companies cope with change by nurturing their people, learning fast, building on what they have learned, and discarding things that no longer work. Surely, that's not rocket science! If that's the case then, “Why,” I ask myself, “write a book about it?” It seems appropriate to begin by offering the reader some kind of answer!

Even moderately large companies can no longer afford to “just get by” as they seek to cope with the challenges of a world of unforgiving change. Business is increasingly moving toward a marketplace model. This model is in sharp contrast to the traditional view of an organization as a production line. In this world, organizations collaborate together, consuming and offering services to maximize efficiency, better serve customers, and achieve long-term advantage.

This is the world of service orientation, in which a hasty decision to outsource an activity may well be a decision that the firm repents at leisure. Equally, focusing the company's own energies on the wrong kinds of thing could be a disaster. The power of technology, from the Internet to grid computing and Web services, is the irresistible force that is fueling this change. Business is increasingly less supported by software and more enabled by it. This means that simply automating business activities in software is no longer enough.

This first part of the book sets the context for the remainder of the book by explaining the principles of service orientation, as a business phenomenon enabled by developments in technology.

Chapter 1 provides a conceptual overview, defines the core terminology and introduces the pivotal idea of service-oriented architecture (SOA). Service orientation presents some massive cultural and technical challenges that cross three areas that have traditionally worked largely in isolation from one another: business process improvement, application development, and software operations. We provide a simple example of how the idea of a service can provide a unifying thread for drawing together these areas, along with some guidance for selling this approach to business management.

The remainder of part 1 maps out the foundation technologies required for practical application. Most of these technologies are developing out of previous well-established generations of technology. At the same time, they are based on standards that are complex as well as changing. Rather than attempting the impossible task of reviewing and documenting all of these technologies and standards we provide an essentially abstract primer designed for maximum resilience to the pace of change; a list of useful evolving Internet information sources is provided at the back of the book. For example, our emphasis is on the general idea of a software service, rather than specifically on a Web service, unless of course the context demands it.

SOA has received its fair share of interpretations. It is a term that is commonly bandied about without clear definition. In fairness, the topic of SOA is probably as much about cultural change as it is about concepts and techniques. However, SOA is integral to the approach described in this book and therefore it is important to define our terms very clearly.

Part 3 of this book lays out the two major aspects of the SOA: policy and structure. We explain how to achieve an integrated approach to SOA that is driven top-down by the BA, and equally that is supported bottom-up by SOM.

Chapter 7 sets the context for the remainder of part 3 by providing an overview of SOA concepts and shows how the essentially static view of the SOA interconnects with the dynamic view of run-time services provided by the SOM. This paves the way for our discussion of SOM in part 4. We also provide an overview of the required changes in mind-set.

Chapter 8 deals with the policy aspect of SOA and provides techniques for the business–IT alignment of policy. We provide an overview of the four main areas of SOA policy – QoS, design, sourcing and usage, and technology – and preview the four key types of QoS requirement – agility, capacity, availability, and security.

Chapter 9 centers on agility, and provides a compendium of service design techniques for structuring the SOA and ensuring business–IT alignment.

A cohesive approach

The IT industry is full of niche comfort zones. One of the unfortunate consequences of the niche mentality is that the execution management of software is treated as an entirely separate subject from topics such as analysis, design, and software development. While separation of concerns is necessary for specialization and discipline, it becomes unhealthy when important interconnections and relationships between domains of interest are ignored – when separation leads to divorce!

In our present context, this trend surfaces in the separation of SOA from both overall operational management of IT services (in a general sense) and the specific execution management of software services. The consequence of divorcing these subjects is extra painful in the case of services. In particular, if services are to adapt in an on-demand fashion, execution management of the services must ensure that SLAs are satisfied, in compliance with SOA policy, with respect to ever-changing run-time conditions. As we argued in chapter 2, these new challenges call for gear shifts in our approaches to service management, toward SOM: a discipline aimed at ensuring that our architectures (BA and SOA) are not just “theory,” but actually reflected in real production running software services.

SOM is dependent upon good specification of the services that it seeks to regulate. To underline a constant theme of this book: “You can't manage what you don't measure,” but more than that “You can't measure what you don't specify.