Treasury Board of Canada Secretariat
www.tbs-sct.gc.ca
Common menu bar links
Government of Canada Service Oriented Architecture Series - Primer
3.0 - GC SOA Overview
3.1 - Introduction
The GC SOA is CIOB's design of a holistic Service-Oriented enterprise model that starts at the business level and permeates down though all levels of an organization down through the technology layers that support the business.
The delivery model for service orientation is based on the theory of the marketplace. If a service has value, then a consumer will use it and if a service has a lot of value, then a lot of consumers will use it. This makes a servicea very important and reusable building block for planning and designing government programs that achieve desired outcomes.
The marketplace also leads to a dynamic community of Service Providers and Service Consumers. In general, entities (people and organizations) that offer capabilities act as service providers. Those with needs who make use of services are referred to as service consumers. Together the service providers and service consumers are sometimes referred to jointly as service participants.
In the sharing and reuse of services, the participants should (but not always) derive mutual benefits. In arms length transactions, providers can amortise their investments over a broader community while the consumers have ready access to desired services without the need to create them from the ground up. In a closed community like the federal government, the service participants work together to achieve common goals such as: Results for Canadians, Horizontal Service Delivery, Service Modernization and greater efficiency in the management of the public purse. In either scenario, they collectively benefit from each other's presence.
At present, the main emphasis of the GC SOA has been restricted to the reuse and interoperability aspects of run-time services only. For instance, services such as a mailroom services, a help desk or a correspondence tracking system are all reusable in a run-time fashion since with some negotiation they can presumably handle the phones calls, mail or tracking for a new community.
There are also many opportunities for reuse during the planning and design phases. For instance, a best practices guide for strategic planning, a template for service level agreements, or a reference model for secure network design are examples of reusable assets that are of value when planning or designing a service. These types of non-operational (runtime) services are not immediately consumable and are not part of the initial scope.
3.2 - Setting the Business Context
Many technical papers have been written on SOA and organizations are already deriving success and benefits from its implementation. It is becoming clear however that having the right suite of reusable services is best achieved when the services are informed by and mapped to the business. In other words, the services should be developed with specific business contexts (or requirements) in mind.
If services are developed with a different set of assumptions then their reuse will be limited. For instance, if someone offers a delivery service, then presumably that service has a high degree of reuse for anyone else trying to move goods. If those goods however include ice cream then all of a sudden the potentially shareable delivery service might not be of value. The designers may have anticipated the ice cream and similar goods and chosen to build the entire delivery service based on climate-controlled trucks. That design however, might include unnecessary overheads for dry goods. With proper business context and a clear appreciation of how the services will be used, it is much easier to make the proper decisions and trade-offs in designing the services.
TBS has already invested in an extensive set of methods and techniques for analysing and expressing the business of government in a common way. The Governments of Canada Strategic Reference Model (GSRM) prescribes a common language used to describe the operations of the public sector of Canada from several perspectives, so individual departments, "clusters" of departments, and central agencies, can more clearly describe themselves and thus "map" common services and the business processes that support them. This GSRM reference model is the first step in achieving a higher degree of interoperability and service reuse. By conceiving and designing services in a common manner, with the intent to make them reusable, the highest degree of benefit from service orientation can be achieved. The GSRM serves as a whole-of-government standard for expressing business services and creating a system of record that can be used in cataloguing services as well as supporting reviews of strategic business designs and implementations.
The GSRM offers 19 distinct service output types that can be used to categorize the many distinct services offered by the numerous federal departments and agencies. These service types are used as the initial classification for business and technical services. As an analogy, recall from your high school physics classes that there are only 6 types of basic machines (the lever, wheel & axle, inclined plane, wedge, pulley, and screw). All other machines, from your basic office stapler to an orbiting space shuttle, are simply the reuse and aggregation of these 6 simple machines.
The 19 GSRM service types have been determined to be the basic building blocks used to deliver all the outputs needed to achieve the outcomes desired for the many federal programs. Individual services can be combined into higher-level services and expressed using models known as SIAMs (Service Integration and Accountability Models). These models can be used to communicate the accountability relationships between the various service providers and service consumers utilized and derived by the Service Negotiation process.
The GSRM also offers generic process patterns for each service output type. This allows for the identification and standardization of services at a more granular level. Drilling into the service process patterns allows departments to identify possible areas of reuse at a more detailed level. For instance each of the service patterns include a process called "collects and accounts for [service name] output fee". With the growth of the Internet, and emphasis on GOL, many departments were increasingly executing this pattern online using credit cards. That spawned the birth of a new service called the RGBB (Receiver General Buy Button). By factoring out a common process and elevating it to the level of a shared business service, PWGSC was able to offer a common approach to collecting fees via online credit cards without the need to have each department reinvent the wheel in this area.
The GC SOA, as a layered architecture, employs the same principles to combine and reuse services to create ever more powerful and beneficial services of increasingly higher order. The reality of this highlights the value of service orientation.
Once we take a process and elevate (and encapsulate) it to the level of a service, there is typically a series of processes that it in turn precipitates. For instance, the RGBB needed to offer departments a means to query a given credit card transaction, perhaps offer refunds or make other billing corrections when necessary. The result is the RGBB evolves into an application with a rich set of functionality all designed to support and manage a shared business service.
The GC SOA therefore starts with the GSRM as a common approach for defining government programs and decomposing them into business services and business processes. This then provides a starting point to contextualize the creation of automated solutions that support the business. Developing an application is after all not about writing code, it is really about addressing and satisfying the business requirements.
Figure 1 - Linking the GC SOA to the GSRM
Thus GSRM based services and processes are often addressed by the implementation of business applications (the top layer of the GC SOA stack). These applications and their many subordinate components (in the SEA and TCA layers) in turn become part of the GSRM resources that help support the business needs.
In the Information Technology (IT) world, business needs are typically addressed through the building (or acquisition) of computer applications. By properly mapping the applications to the business, the organization's agility and adaptability is significantly increased. Clearly if there is a one-to-one mapping between an application and a business function then dropping or changing a business function would have impacts on the one underlying application and presumably not cause a chain reaction across many applications. Conversely, if an application addresses a wide multitude of business functions, the application is constantly being impacted every time some element of the business changes.
3.3 - Deriving Value from the GC SOA
As demonstrated earlier, there are significant advantages to being able to take a complex machine and express it as a series of simpler machines. In the IT world, complex systems can be expressed as a series of small discrete units called components. When service-orientation is applied to an application, we increase its resilience to change and make the individual components more reusable. This decomposition process is repeated resulting in several layers. The magic is to try and manage the overall process by having a clear approach to decomposing the application in a systematic manner and have a rationale for knowing how to organize the many components into distinct layers. This is the heart of the GC SOA reference architecture.
By introducing these layers in a formal manner, industry has shown the value of Service Orientation to be in its ability to:
- Facilitate the manageable growth of large scale enterprise systems;
- Provide a simple scalable paradigm for organizing large networks of systems that require interoperability;
- Minimize trust assumptions among providers and consumers to promote greater business agility and autonomy; and
- Integrate functionality across ownership boundaries.
The key to making these benefits real is to generate momentum for the creation and reuse of services. Collaboration is needed to have providers create and register a portfolio of reusable services,
plus make it practical for them to be discovered and shared by potential consumers. This collaboration model can be represented in the following manner.
Figure 2 - Service Negotiation process
