Examples
From PGFSOA Wiki
Contents |
[edit] Please Supply your Suggestions:
- (Edit this text: Example for Section x.x.x)
- (Example for Section x.x.x)
- (Example for Section x.x.x)
[edit] An example primer showing SOA relationship to the FEA Reference Models and Segment Architecture
This is an illustrative primer and example of a possible approach for a Federal Enterprise Architecture driven SOA strategy. A simplified Financial Segment is used for illustration. This example is for the SOA space and only touches upon SOE and SOI in the discussion of basic (simplified) governance. As the FEA Reference Models are not prescriptive there are other possible valid approaches to this “middle out strategy”, such as those driven completely by process and those driven completely by wrapping data. Depending on the circumstances other approaches may be more appropriate for the organization. “Ideally”, the SOA would be driven by business process.
There are two initiatives to make EA more connected, integrated and actionable. These efforts are Segment Architectures and Profiles which contain prescriptive methodologies. Segments are an organizational unit for enterprise architecture, whereas services are an organizational unit for technical implementations. As organizational units for enterprise architecture, their depth includes not just the technical, but also the business and the data architectures (Sessions 2007). Segments are critical to EA driven actionable SOA.
SOA and Segment Architectures are the major future touch point between EA and Solutions Architecture. Figure 1 shows an idealized boundary between the communities and is helpful for understanding the interaction. It is important to note, that these boundaries are idealized and are not likely to exist exactly according to this model at all agencies, the lines need to be adjusted to the particular environment.
[edit] Segment – Solutions Architecture Background
Recent publications by the OMB have taken significant steps to integrate with the Solutions Architecture communities of practice through the concept of segment architectures (OMB 2006), they are a comparable concept to Business Elements in the Model Driven Architecture (MDA) community. Segments are a decomposition tactic allowing focus on relatively independent chunks of the Enterprise and have been in practice for some time (Bernard 2005). Agencies will have core mission area, business service and cross-cutting Enterprise service segments such as Security, Records Management, and Geospatial. Segments will be of flexible scope, and will be useful within an agency, across several agencies or the entire federal government. FEA Practice Guidance describes the relationship between EA and Solutions Architecture as “Solution architecture is commonly related to segment architecture and enterprise architecture through definitions and constraints. For example, segment architecture provides definitions of data or service interfaces used within a core mission area or service, which are accessed by individual solutions. Equally, a solution may be constrained to specific technologies and standards that are defined at the enterprise level.”
Segment Architecture guidance recognizes that development will be triggered by both top-down (strategic) and bottom-up (tactical) drivers and that feed-back loops and process will be required; this is movement toward recognizing the constraints on real or actionable IT strategy. The loop and tactical drivers will be more effective if EA teams are knowledgeable of the frameworks, use the language, methods and notations that are ubiquitous in Solutions Architecture domain, the Unified Modeling Language (UML) and BPMN (SOA) are illustrative examples.
Borrowing a term from this domain, the EA will constantly need to be re-factored if not done at an appropriate level of granularity and abstraction and integrated with the activities of the Solutions Space. This granularity of services is likely to be environment specific, for example course service definition at the Department (EA or Business “service”), finer at the Agency (possibly EA and SOA service) and finer yet at the Solution (SOA Service). EA and Solutions Architecture can harmonize by developing a SRM based extended model that considers both the business and relevant Solutions frameworks and service implementations. For the simplicity of this example there are three basic types of web services: task-centric which represent business processes such as order fulfillment (a controller pattern – BPMN, BPEL), entity-centric that represent the business data and its associated behavior or functions and infrastructure services (SOI) such as a security service. The business process models from an EA can optimally be implemented directly in a task-centric orchestration engine such as BPEL, the accuracy of these models and the ability to transform them into new desired states for the business will represent a form of “business alignment”. The goal is to design services that are understandable to the business or mission. It is very useful to have conceptual data models (DRM) that can be used to determine gaps in COTS or provide language describing the problem domain
The Federal Enterprise Architect is more likely to influence SOA by taken it up a level of abstraction to the SRM and most SAs will appreciate the help in the area of task-centric business process based services where EA can provide the needed enterprise view and influence. The boundary between EA and SA in the SRM is currently not clear or generally accepted by either community (Smith, O’Brien, Kontogiannis and Barbacci 2002). The boundaries depicted in Figure 1 are idealized and they do not account for Solutions Architecture Methods such as ATAM which are based on customer sponsor stakeholders (not “just” users and developers). EA and Solutions Architecture Methods provide best practices related to SOA, and should probably be strongly considered but should be tailored for the agency environment. There appears to be opportunity to integrate the EA oriented methods such as the open-source Method for Business Transformation (MBT) (Coggins, Speigel 2007) with SA oriented methods such as the SEIs ATAM and SMART effectively implementing the necessary feedback loop discussed earlier.
[edit] Financial Segment Based Example
Financial systems are ubiquitous across agencies, follow GAAP standards and best practices and are an area of Federal LoB related Data standardizations such as Common Government-wide Accounting Classification Structure (CGAC). These attributes make the financial domain a good choice for an illustrative example. Theoretically, SOA should be driven exclusively by process but for the practical guide as the old saying goes “in the theory there is no difference between theory and practice, but in practice there is”. The process artifacts are the least likely to be in usable state of quality and granularity for our purposes. This is why in the wild, SOA is most likely to be from a “bottom-up” data wrapping type approach. This is confirmed by experts: “Maybe I live in a different universe, but most enterprises I work with admit to highly fragmented process models with variable levels of quality and relevance to the real world. For all the hype over BPM, the reality is that most processes are still documented in code and procedures manuals if they are documented at all. So EA process models I have reviewed demonstrate a triumph of hope over experience, as simple questioning reveals vast duplication and inconsistency of process naming and functionality”. (CBDI Journal October 2007)
Figure 2 shows a basic FEA based decomposition approach that will be used in the example and a connection between layers for the SOA approach. Processes will still drive the SOA but they will be classified within Agency Functions which themselves will be classified within FEA Sub-functions. This approach is consistent with the FEA which is a structuring, classification and assessment taxonomy. Segments are also a decomposition tactic allowing focus on relatively independent chunks of the Enterprise and have been in practice for some time (Bernard, 2005). The segment in this example is the vertical FEA stack for a Financial Segment or Line of Business (LOB). This approach is also appropriate for the government as we support constrained “missions”, even though it may be common to refer to the non-IT components as “the business”, they really are not analogous to a GE that may be in the finance business, the light bulb business, jet engine business, none of the agencies are intended to move from one profitable area to the area. Areas of overlap with other agencies/business should be identified for the possible of using a Shared Service Provider (SSP) allowing the agency to focus on core mission areas.
--Joe V 15:27, 8 May 2008 (EDT)
[edit] Scenario and Example
This example is massively simplified to provide clarity. In this scenario the agency has designed a payment process classified under the appropriate FEA based structure. The use case is to make payments to a citizen. Services should be loosely coupled, chunky and not chatty. The services required have been identified as the Payment Process (task-centric) Service which will be implemented in the Business Process Execution Language (BPEL). There have been 3 entity-centric services identified:
- Customer Validation Service – This service will include the related sub-processes and will verify the Citizen is OK for payment. For the simplicity of this example, this is accomplished via web-service(s) that wrapped the API and capability of a standard Financial COTS.
- 3rd Party Banks Payment Service(s) – In this example a bank or another SSP is actually cutting the check as well as handling the mail or EFT services associated with making payment to the citizen. This activity may be performed by multiple SSPs based on attributes like geographical location, the amount of the payment etc.
- Service to Update Customer Account – In this example the bulk of this not “inherently governmental” work is performed by the 3rd party. This service simply updates the books after the payment has been made.
The services represented here are at an EA level of granularity it is likely for example that Solutions Architecture will require multiple web service calls to determine if the customer is valid, such as calls to legacy or unconsolidated systems. This example is depicted graphically in Figure 4 with only enough detail to provide line of sight between the layers.
