The OsEra Enterprise Architecture Methodology builds on the Model-Driven Architecture (MDA) concepts and applies them to the enterprise level. MDA, as defined by the Object Management Group (OMG), is a framework that defines three levels of models, where each successively more specific model conforms to the models at the previous levels.
· The Business Model or Computation Independent Model (CIM) is a model of business processes and information. There is no mention of systems or technology at this level.
· The Platform Independent Model (PIM) is a technology-neutral system specification that conforms to a business model. This model reflects decisions on how information systems will be used in order to automate or accelerate some part of the business model, independently of the specific technology platform or platforms that will be used to provide this automation.
· The Platform Specific Model (PSM) is a technology specification that conforms to the PIM system specification. This model reflects choices of specific platforms in such areas as middleware technology, database technology, client software, application servers, etc.
The OsEra EA Methodology focuses primarily on the CIM and PIM models while the PSM is managed through the provisioning facilities of OsEra.
Business Model or “Computation Independent Model” (CIM)
It is the responsibility of the CIM to model the business concerns and designs of the enterprise. OsEra specifies a combination of different modeling views to express these business concerns: value chains, activities and role collaborations. All of these approaches share a common goal—to express how value is delivered to stakeholders. Identification and delivery of value is focused externally, how the organization delivers value to its customers and utilizes its supply chain. This “pattern” of value analysis facilitated with processes, roles and responsibilities works when analyzing the enterprise at large or when looking at a service organization within the enterprise.
OsEra modeling views frequently start with the business context, or the enterprise and its customers and supply chain. Successive detail is then developed along the value chain/process or role/collaboration view. At any level a collaboration role may provide a value chain view. The fully elaborated detail from either view results in activities that produce and consume information. The result is a specification of the enterprise processes that can be performed by the enterprise staff and contractors and enabled by their IT system.
Value chain analysis is an important part of the existing OsEra business centric approach.
The essential kinds of value chains are:
· Mission critical value chains are those that directly provide external stakeholder value. In the existing OsEra business model there is one generic mission critical value chain. As OsEra is developed in more detail we expect multiple value chains, each corresponding to a customer value proposition.
· Discipline value chains show how broad areas of responsibility within the enterprise, such as finance or HR, contribute to the enterprise. Discipline value chains may either be part of mission critical value chains or may serve “internal customers”—such as HR.
An essential element of value chain analysis is the line-of-sight from customer value through to the processes that support that value and the value chains that indirectly support those processes. These relationships are established in the business model by traversing between the value chain and collaboration views through the shared activities.
The other primary business view used in the existing OsEra models is that of roles and collaborations. A collaboration is a model of a closed set of roles that participate in mutual interactions in order to achieve some joint purpose. Each role is responsible for performing a specific function in achieving that purpose. Ultimately, for each role, something or someone—an actor—must “play the role” (i.e., exercise the responsibility) for it to be realized. An actor can be a specific individual, an organization or a technology performing the function represented by the role. This is a familiar paradigm of roles and responsibilities.
Giving meaning to roles within a community process requires the identification of the “conversations” or protocols that take place between the actors playing these roles. Each protocol represents a specific conversation between two roles that is necessary in order to satisfy the roles’ responsibility within the overall process. While a typical protocol involves two-way communication between the conversing roles, a protocol is initiated by one of the two roles, with the other role initially responding to this stimulus.
Note that protocols may be as complex and nested as necessary to capture the interactions between actors playing the roles involved. At the lowest level, protocols define the specific messages interchanged between roles during their conversation—providing a direct tie to SOA.
The role/collaboration view of the OsEra business model is currently organized around the disciplines of Financial Management, Human Resources, Marketing, Acquisition, Solutions and Policy, with their corresponding value chains.
While the existing OsEra business model does group roles into packages according to the various disciplines, it does not include any explicit overall view of the business interactions that occur between roles across the disciplines. Rather, these interactions are implicitly modeled on the various collaboration diagrams of a discipline whenever a role of a different discipline appears. In order to make this more explicit, the team decided to create discipline roles for each discipline, clearly delineating the interactions one discipline has with the others. For example, there is an Acquisition Accounting protocol representing the interaction of Acquisition with Financial Management and a Strategic Planning protocol between Financial Management and Policy. Discipline roles also provide a connection between collaborations and value chains, with the discipline roles closely matching the current discipline values chains.
The protocols on a discipline role are composite roll up protocols that identify all the touch points between the discipline and other disciplines. For example, the Acquisition Accounting protocol is actually composed of lower-level protocols representing each of the various interactions that may take place between Acquisition and Financial Management in the course of carrying out various business processes, such as Obligation Submission and Invoice Submission.
An analysis such as this across the OsEra disciplines leads to the clear identification of all the dependencies between those disciplines. As part of the FMEA effort, the FMEA team has identified in detail only the protocols related to the dependencies between the Financial Management discipline and other disciplines. During the course of BPA tasks such as the sample tasks, it is expected that a similar level of detail will be provided for the other discipline roles.
Within each OsEra discipline, such as Financial Management, the business model defines a set of top-level roles, such as Receivables Accounting. We call these enterprise roles. Figure 1 shows schematically the refined set of Financial Management enterprise roles that resulted from the FMEA effort. One can think of roles at this level as a kind of “virtual departmental organization” of work within the discipline (“virtual” in the sense that no commitment is made in the model to the enterprise actually organizing its personnel in exactly this fashion). This level of decomposition is also consistent with the sub-function level of the FEA Business Reference Model (BRM).
The protocols on enterprise roles are at the lower level of the roll up protocols. For example, the Obligation Submission protocol within the Acquisition Accounting roll up is actually provided by the Payables Accounting enterprise role within the Financial Management discipline, as shown in Figure 2. Enterprise roles also interact with each other using such protocols. For example, the Payables Accounting enterprise role uses the Receivable Establishment protocol to establish a receivable for billing with Receivables Accounting for a reimbursable expense.
The interactions modeled by the protocols on enterprise roles are at the level of individual business transactions. That is, each such interaction involves a request for a specific business service to be carried out by the enterprise role. This service is then either carried out successfully, changing the business state of the enterprise role, or it is rejected, having no effect on the business.
For example, Figure 3 shows the business transactions involved in the Receivable Establishment protocol. The Receivable Establishment transaction, with the same name as the protocol, represents the major business service that is requested using this protocol—the establishment of a receivable. As shown, it is also possible to request a Receivable Correction, to correct a receivable previously established. In either case, the transaction is either accepted and completed by Receivable Accounting, with a Receivable Accepted response to the requester, or it is rejected, resulting in a Receivable Rejected response.
The existing OsEra business model generally specifies the behavior of various enterprise roles directly in terms of the activities carried out by those roles, which are then related to value chain processes. As the CIM for a discipline is further detailed, it is necessary to provide a further organization of the activities within the enterprise roles into sub-roles, which we call work roles. The activities grouped into a work role are typically at the level that they could be assigned to a single worker or supported by a specific function in an information system. They are also at the level of individual business processes within the FEA BRM.
For example, the Receivables Accounting enterprise role is decomposed into four work roles: Receivables Management, Billing, Collection and Delinquency Management. Each business service protocol provided by the enterprise role is actually carried out by one of the work roles. For instance, the Receivables Management work role (shown in Figure 4) handles the Receivable Establishment protocol. Interactions between work roles (such as the Charge Establishment protocol between the Receivables Management and Billing work roles) are also at the same business transaction level as the protocols defined between the enterprise roles.
Activities and Subactivities
The behavior of a work role is defined by the activities carried out in response to requests for business transactions. For example, as shown in Figure 4, the Receivables Management work role includes an Establish Receivable and Accrue Revenue activity that handles the Receivable Establishment transaction. In carrying out a transaction, an activity will often also initiate additional transactions with other roles. For example, establishing a receivable may result in the establishment of a charge to be included on a future bill.
These activities are at a level consistent with the activities in the existing OsEra business model. Indeed, the activities already identified in the existing model must be the starting point for any detailed drill down.
It is at the activity level that detailed validation needs to be carried out with the enterprise personnel. Ultimately, the definition of these activities must clearly capture the desired behavior of the target business processes. To do this, each activity may be choreographed, either in terms of lower-level sub-activities, or directly in terms of the expected flow of responses to requests handled by the activity.
Further, the organization of activities in the CIM provides a framework for allocating business requirements and business rules identified from sources including external mandates (such as those from the Joint Financial Management Improvement Program—JFMIP), the enterprise policies and plans, and interviews with the enterprise subject matter experts. For example, business rules associated with the Establish Receivable and Accrue Revenue activity include the following (among several others).
· If the receivable being established is associated with a customer order, then that customer order must not yet be completely filled.
· If the customer order associated with the receivable has an available balance on advances, then that must be used to cover the receivable.
· If the available balance on advances is less than the amount of the receivable, then the remainder of the balance of the receivable must be established as a charge to be billed.
In addition to modeling the business processes of a discipline in the CIM, it is just as important to model the business information acted on by those processes. Such an information model begins as a formal model of the vocabulary of the discipline and the relationships among the vocabulary terms. This model is then extended with detailed attributes that belong to each vocabulary term (such as the subsidiary information for a Receivable), drawn from data elements identified from existing architectures and through legacy analysis as well as general terminology from subject matter experts.
The model is diagrammed in the industry standard Unified Modeling Language (UML). For example, Figure 5 shows how this notation is used to represent a simplified model of bills. It is important to note that, while UML is often considered to be a software modeling language, it is being used in the CIM to represent a vocabulary (or ontology) of business information concepts, not a model of data as it might directly be represented in an information system.
The information model provides the consistent vocabulary for two very important areas in the process model. First, it specifies how information must be recorded and how it may change over time as a result of various business processes (such as a receivable moving from being unbilled, to being billed and then being paid—or becoming delinquent). Second, it defines the content of all the information that flows between the various roles, people, organizations and activities that interact during the course of any business process (such as the information that flows into Receivables Accounting as part of the business transaction to establish a receivable). A particular goal of an information modeling effort is to consolidate redundant and inconsistent terminology (while maintaining a record of synonyms), allowing essentially common processes formerly handled quite separately to be handled in a common way.
The PIM provides a model of system components, giving a technology-independent specification of how the roles and collaborations in the CIM are to be implemented. The overall composition of components into a system defines a logical system architecture. In additional to components that support or implement various business processes, such a system architecture must also include components that explicitly deal with the interface between human users and automated systems and with the management of persistent data over time.
In order to organize the different concerns of system components, the common best practice is to organize components into presentation, application and data tiers. There are thus three corresponding sorts of components.
· A presentation manager component provides user access to application services.
· A service manager component provides transactional implementation of application services.
· A data manager component persists data between application transactions.
A crucial goal in constructing the PIM is to ensure that the system architecture so defined accurately and completely addresses the business requirements specified in the CIM. As described in the following, our MDA methodology achieves this goal through our approach for constructing the PIM by effectively elaborating the PIM.