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.
Continued: Maximizing reuse
Related content:
Blocks of SOA: Building services with common symbols
SOA: It's architecture, not technology
SOA: Understanding the architecture
Where to start SOA: Identifying the big business driver
SOA at work: Ontario's common components
icon.
