Framework supports enterprise scope to transform business
Taking an enterprise view can help to guide an organization to improved planning, decision-making, communications and business direction. It’s also time-consuming and requires ongoing investment to support.
It’s not a one-time quick fix, either, for the enterprise hairballs generated over the past 40 years of fractioned, uncoordinated initiatives. The value to the enterprise is driven mainly by reducing or addressing conflicts that will occur across the enterprise view and direction.
The promise of service-oriented architecture (SOA) is the ability to better automate business processes and implement changes quickly, while reducing service costs and increasing service reliability and quality. As with other technology approaches, SOA does hold potential for service or business improvement. But not by itself: SOA is simply an architecture option or framework to be considered within the government business.
Before an organization can launch into an SOA framework, it must first understand its business processes. SOA projects have typically started from either a top-down or bottom-up approach.
From a top-down perspective, a functional area is selected and the context diagram is built out, thereby identifying services to consider for automation. The bottom-up approach starts with a brainstorming of service ideas by subject matter experts, followed by defining the service requirements and fitting the service into the context diagram.
Either approach works, and several frameworks are available to assist, including Zachman’s enterprise architecture framework. The federal government’s inter-jurisdictional Business Transformation Enablement Program (BTEP) specifically targets the top two levels of Zachman’s framework, which define the enterprise scope and conceptual business model and provides a consistent top-down approach.
BTEP provides a common language for business transformation in government, with a clear view to the common functions across the entire enterprise. From BTEP’s executive overview, we see it provides “a way to get a clear, holistic picture or view of all of governments’ business processes and their context.”
The common language provides government the ability to better understand process interaction and identify where common business processes exist. The BTEP toolkit uses a public service language that all participants in government should understand, including deputy ministers, assistant deputy ministers, directors general and directors, along with systems architects. It supplies the bridge of communication between executives and systems architects.
Once this process view is understood, an enterprise can choose to manage moving forward on an integrated enterprise basis, using an SOA as the basis for creating the building blocks required to enable the business process transformation. SOA provides the guiding principles and framework to direct the design, construct and implement the BTEP-identified common business processes into common services.
Most new IT terms, like SOA, tend to take on various definitions and meaning. As it gets better understood and embraced, the industry refines the definition. Wikipedia is a great tool for housing definitions along with providing a means to refine the definition by the global community. Additional definitions can be found through the various standards organizations, but these tend to come out only after the industry leaders recognize the concept.
A key concept within these definitions is that SOA uses loosely coupled services that are accessed without the knowledge of the underlying technical implementation of the service. The service request is made and an understood response is provided.
To help identify which services to consider for automation, the government service value propositions must be determined. While BTEP can assist with determining the value propositions, the government must determine its priorities and which to move forward with.
This decision process should also identify the project sponsor. Typically, the business or government sponsor will not understand SOA and have no clear reason to support using SOA on the project. The value of SOA must be articulated and evangelized to get this support.
Some generally perceived benefits of SOA include:
- The architecture is durable and allows the business or government to adapt and grow; organizations that fail to evolve often fail.
- SOA breaks down large, complex systems into modular units or reusable services.
- It loosely couples these services together, using standard protocols.
- The framework better supports communication and collaboration between business and IT.
- SOA is fuelled by standards that have been agreed by virtually all major technology players.
- It encapsulates business policy.
- The architecture enables process integration to occur.
These benefits must tie back to the project’s measurable business benefits and the executive sponsor must fully support them. The executive sponsor should help secure adequate funding for the project.
Initial SOA projects will set the standards for future projects and will reflect the success of the SOA introduction. Sufficient budget must be allocated to support the additional effort required to build and learn the new standards, processes and technologies that come with SOA.
As well, reusable services tend to take more effort to build as both current and potential future business requirements are considered, to ensure the service is reusable. But the reusable benefits are worth the extra expense.
The challenge is also to enforce the reuse of services at an enterprise level.
If reuse is unable to occur, then the enterprise-wide hairball that we saw occur over the past 40 years will continue to exist, within a complex multiplicity of SOA frameworks across an organization.
To support a successful SOA project, the services to be implemented should be well used by a number of government departments, thereby providing project visibility and service reuse. Scope the project to produce results in less than six months if possible to help showcase the positive results and allow you to make adjustments to the standards, processes and technologies based on lessons learned.
But don’t stop there, the investment and focus must be maintained, as it can take several years to fully establish SOA within government.
Early on, be sure to establish a SOA governance model to help set the standards and manage the risks. A SOA governance board should be developed within the context of the overall governance framework, typically a subset of your enterprise governance.
Some of its goals would be to include facilitation and control of the service utilization across the entire government, oversee service reuse and stop service abuse, leverage infrastructure and resources to reduce additional costs, establish and maintain the high-level principles to be applied, and reduce project risk.
Arguments can be made whether a centralized or federated SOA governance model should be followed. Either works fine, but it should ultimately line up with the existing organization structure. Frequently, organizations tend to start with a centralized governance model and then move to a federated model after a number of successful SOA project implementations.
Finally, when undertaking a SOA project, there is much planning to undertake. Items to consider include security, performance, and service definition and availability. Some considerations:
- How will security be managed as services are requested from multiple sources? Role-based models are being implemented to support this.
- Is the service designed to support the transaction volumes; do you understand the transaction volumes once the service is available across the enterprise? Consider the requirement for an enterprise service bus to mediate between the services.
- How will the service be shared and made available for use?
Ultimately, strong SOA knowledge and a dedicated team should be assembled to start the project and help evangelize the standards and decisions made, guiding the government to a more consistent approach of implementing and supporting citizen-centric services.
Frank Burghardt is an enterprise architect with EDS Canada Ltd. Contact him at frank.burghardt@eds.com
Related content:
Blocks of SOA: Building services with common symbols
SOA: It’s architecture, not technology
SOA: Understanding the architecture