|Okon, Walt, Computer Engineering - Electronic Business Architecture
Version 4.0, www.waltokon.com, 04 October 2002
|Electronic Business Architecture
By: Walt Okon
Chief, Electronic Business Engineering
Defense Information Systems Agency
When engineers design and develop Architecture of the past, they are dated and become shelf ware as soon as it is printed. The challenge for the Department of Defense (DoD) is to create a “living” on-line DoD EB Architecture that has the capability of providing system design descriptions and interconnect descriptions for all DoD systems related to Electronic Business. This development of this DoD EB Architecture constitutes a paradigm shift in the overall approach to managing the development of EB for the government. Whereas past architecture approaches have been top-down efforts within a particular organization or functional area, this effort seeks to facilitate communication across functional communities and across organizations. It is service oriented architecture.
Figure: The Royce Waterfall Process Model
The Royce Waterfall Process Model as described by Dr. Patterson is the closest model which could be used to describe the development of the DoD EB Architecture. The software design and development team was composed of the following sub teams; Functional Customer, Requirement Analysis, System Integration, Program Design, Development, Testing and Operations. All sub teams work in parallel and attend the weekly EB Architecture Working Group development meeting for information cross feed, action taskings, and delivery. The weekly EB Architecture Working Group development meeting is the constant feedback mechanism between all the sub teams and the stages of the process model.
System Requirements: Prior EB architecture efforts concentrated first on developing a common means of expressing the business processes of the Department in a way which would both comply with the DoD Architecture framework and allow cross-functional architectural analysis. The last paper Version 3.0, published in July 2000, applied the framework to the work done by the End-to-End Procurement Process IPT in defining the interrelationships between and within Procurement, Finance, Acquisition, and related communities involved in the contracting process. This exercise served as a proof of concept that the EB Architecture framework could be used to map a cross-functional business process, describe systems, and define interconnects. Nevertheless, it was also apparent that the process used in actually writing the EB Architecture 3.0 document was not adequate to support expansion across the entire DoD. The result of such an attempt would be an ever-increasing stack of outdated documents labeled architecture.
Therefore, in an effort to make architecture meaningful and useful, the Functional Customer Team defined the Statement of Work (SOW). They divided the System into components. The first piece provides guidance on using the framework in a common way to define business processes in a cross-functional, cross-organizational manner. In effect, this serves as a language for communicating capabilities and needs across the department. The second piece, capturing the actual capabilities and needs, is an application of EB technology to managing EB. It consists of a web-based registry in which system owners and customers can communicate both user needs and system capabilities across the department. This will enable the department to grow the architecture in a distributed fashion, without creating additional bureaucratic layers. The registry can serve as a marketplace of solutions, allowing working level managers to re-use existing capabilities that might not otherwise be visible.
The Software Requirements Team has the responsibility to work with the Functional Customer Team, accept the SOW, review, analyze, and develop the Software Requirements Specification (SRS) along with a traceability matrix. The SRS defines the requirements, case models, process and cost models. Derived requirements must be traced to the SOW and elicitation and validation is accomplished with both the Functional Customer Team and the actual customers.
Requirement Analysis Team and the System Integration Team seem to function in the Analysis part of the model. These teams have two different core skills and at the same time are all working on different phases of the SOS, the SRS, and the Requirement Traceability matrix.
The DoD architecture embodies an expectation that there will be innovation in the department as local functional communities find solutions to local problems. However, it is rare for a problem to be unique to a functional community or organization. While DoD seeks to minimize duplication, it recognizes that past efforts to centralize development and build one-size-fits-all solutions from the start have proven unsuccessful. Thus, the intent is to serve as a mechanism to create a marketplace of good ideas, which can then be migrated beyond their birthplaces in individual Services and Agencies to a wider DoD audience. This recognizes the advantage that the individual components have by virtue of their close relationship with a set of customers. By building from small successes, DoD can more rapidly and efficiently create a world-class infrastructure for EB without the delays inherent in any large centrally bureaucratized effort. In this way, DoD can use its own unique culture to leverage the speed and flexibility which has given the private sector such success in developing and implementing technology.
Figure 2. DoD EB Architecture
It is during the Analysis process that the architecture system design is finalized. The department develops visibility into its business processes and related systems, a common operational picture of the business side of the department should emerge in the system design as in Figure 1. By having visibility into the operations of its components, the department can both make reasonable decisions about how to support the processes, and could reallocate work as needed in time of national emergency. This means that the DoD EB Architecture can define any and all systems world wide once loaded. The EB Registry is the input and output of a data base that hold all media data for all system. The Architecture Tool (System Architect 2001) connects the components and produces the “Views” of the systems and their interconnects. All wrapped in Web technology used to search, deliver, display the systems and the strategic guidance. This system of components wrapped in Web is the “living” architecture.
This is were the System Design (both High level design and low level design) is accomplished by a combined work effort of the Requirement Analysis, System Integration, Program Design, Development, and Testing Teams. It is important to note that the Program Design, Development, and Testing Teams have been involved from the beginning of the SOW and have been planning and developing their activities. However, now they become the dominate players do the design and beginning the development. Prior to this they have been assisting by building the prototype, configuring it, and testing it. They are looking at the integration of Commercial Off-the-Shelf (COTS) products.
Coding is done during the development phase; it is the core of development. They work in accordance to the International Standards Convection and the published Joint Technical Standards. We have not talked about the test team.
The Test Team has been working on the Test Plan and the Testing scripts all of which are based on the SOS, SRS, SDD, and FDD. The Test Team is responsible for the four phases of Testing; Development, Functional (IV&V), System Integration, and Operational Acceptance Testing. These four testing phases must be fully coordinates with the other teams.
The Operations Team is made up of the system operators who interface directly with the customers or users of the system. Since they must operate and deliver the product they are the ones that do the Operational Acceptance Test (OAT). They accept the new system on behalf of their customers. Also, they identify problems and feed the error reports back to the other teams. They are a key part of the feed back loop. Another feed back process is the Configuration Control Board (CCB) for the system. The CCB is chaired by the Lead Engineer and the Chief of Operations with a representative from each of the sub teams; Functional Customer, Requirement Analysis, System Integration, Program Design, Development, Testing and Operations
Royce Waterfall Process Model was the bases for the software development of the DoD EB Architecture during the past eighteen (18) months (February 2001 through August 2002). Although the Royce model suggest that only one process is active at a time, our development strategy had all teams working their processes in parallel with constant cross feed. Each week there is a Integration/Crossfeed Working Group Meeting. In this way, feedback and correction was possible and effective at all stages of development. The Electronic Business Architecture Version 4.0 “live” system was delivered to the Office of the Secretary of Defense in August 2002. It is "Up and Running", and a briefing and demonstration will be provided upon request.