Evolving the Enterprise Using NetCentric Operational Architecture
by Rob Byrd, Chief Enterprise Architect
Differences between Structured Analysis and Object-Oriented
Developing a Service-Oriented Operational View
Our UML Service-Oriented Framework
Spirally Evolving to Service-Oriented Architecture
A Case for an Enterprise Architecture Center of Excellence
Using SOA for Capability-Based Planning
Download PDF Version: NetCentricOperationalArchitecture.pdf
Understanding the Problem
|
We Describe How to Evolve Stovepipe |
We recognize that for various reasons, some large enterprise systems evolved in a stovepipe fashion. We theorize that the current stove-piped state of affairs is a result of past system engineering practices and many technology experts believe this occurred because legacy systems were not developed from a service-oriented perspective. Traditionally, enterprise analysts use a structured analysis system engineering approach to analyze the enterprise to identify improvement options. Although structured analysis, frequently referred to as Integrated Definition (IDEF), provides great value in understanding the controls and mechanisms that implement the process, it is less efficient in describing the operational or business process from a service-oriented perspective when compared to newer modeling languages such as the Unified Modeling Language (UML). To add to the confusion, many system engineers have the viewpoint that the UML is primarily for software development resulting in no value to overall enterprise analysis.
The good thing about the UML is that it has many abstraction mechanisms, customizable stereotypes, multiple association types, classifiers and behavioral views. The bad thing about the UML is that it has many abstraction mechanisms, customizable stereotypes, multiple association types, classifiers and behavioral views; and therefore, less likely to be accepted by system engineers familiar with simpler approaches such as IDEF. However, when the enterprise analyst thoroughly understands the UML, an object can represent an organization, role, ground station, space lift vehicle, sensor, server, etc. Not unlike a software service-oriented model, an operational service model is a conceptual description of the structure of operations in terms of its entities and the services they provide, without regard for the underlying implementation of these entities, services and connections between them. In essence, a well-developed service-oriented operational model describes business or operational components representing process (operational activities) for reuse throughout the enterprise.
The object-oriented UML method allows for loosely coupled extendable and adaptable process in a comprehensive industry standard lexicon. Alternatively, the tightly coupled structured analysis approach results in large maintenance issues because changes at higher levels of the model cause major ripple effects to lower levels of the model. The structured approach also lacks in closure in that functional responsibility is unclear at the edge of the enterprise, yet these dependencies are important to investment decisions. UML’s loosely coupled mechanisms have no rippling effects as you mature the operational model and the method ensures closure using UML entities containing functional (service) responsibilities within and at the enterprise boundary. We believe complex enterprises require a repeatable method to manage functional responsibly among the many systems and organizations collaborating to achieve a desired capability or effect and service-orientation needs to begin at the business or operational process while describing the realization of desired capability.
We offer a modeling process both extendable and expandable to include an architecture animation approach unlike any other. Using our UML method, architects and designers can think through the desired capability in terms of operational process, identify technology gaps and shortfalls, eliminate or seriously reduce rework, and achieve stakeholder buy-in. The resulting models deliver understandable requirements, community of practice buy-in, a service-oriented integrated enterprise, and a framework from which to manage changing mission needs over time. Using our approach, the enterprise achieves a proven process and tools to manage capability development using end-to-end enterprise architecture as the basis for knowledge management, portfolio management and capability-based planning.
We believe, to achieve enterprise objectives, the enterprise must come to grips with their business processes and the underlying services and technologies that implement them. A service-oriented business model provides an effective framework in which to analyze existing capabilities to employ, deploy and develop operational capability using plug-and-play operational services.
Differences between Structured Analysis and Object-Oriented
Many viewpoints exist regarding the various architecture modeling methods used by the Department of Defense (DoD) and there are significant differences between a structured analysis and an object-oriented approach. Typically, these opinions stem from past experience, expertise, tooling, and understanding of the value each approach provides. Due to the complexity of the methods and the architectural understanding needed, it is difficult to convey to the non-architect the significance between the two methods. In fact, you must genuinely understand both methods to comprehend these differences. Moreover, DoD governance sometimes adds to the dilemma by identifying preferred tools and methods without consideration for the purpose and needs of the architectures used by the architecture organization. The fact that both methods capture DoD Architecture Framework (DoDAF)-compliant views further complicates tooling decisions. Both methods provide a way to capture critical architecture data needed for key DoDAF operational and system views. In addition, both decompose complex problems into a collection of smaller, more manageable parts and provide graphical representations of the problem. However, the approach used by each method is completely different.
|
Functional decomposition describes process |
Structured Analysis
Structured analysis typically creates a rigid hierarchy employing a single abstraction mechanism. The structured analysis method typically employs IDEF, is process driven, and starts with a purpose and a viewpoint. This method identifies the overall function and iteratively divides functions into smaller functions (sometimes referred to as activities), preserving inputs, outputs, controls, and mechanisms necessary to optimize processes. Also known as a functional decomposition approach, it focuses on cohesion within functions and coupling between functions leading to structured data.
The functional decomposition of the structured method describes process without delineating system behavior and dictates system structure in the form of required functions. The method identifies inputs and outputs but not interaction with the external source and destination. Because the method focuses on coherent sub function structure, it can break up information objects in favor of functional boundaries, impeding future reuse opportunities and process consistency.
One reason for the popularity of structured analysis is its intuitive ability to communicate high-level concepts, whether single system or enterprise levels. Discovering how objects might support functions for commercially prevalent object-oriented development is unclear. As a software development tool, however, IDEF lacks the ability to model object-oriented processes and services.
Object-Oriented Analysis
In contrast to IDEF, the UML is data and highly interface driven with multiple abstraction mechanisms. The object-oriented method starts with the stakeholder and the operational activities required in a service-oriented way. The method identifies a use case (ways the user employs or makes use of the system) to generate important results – also known as results of value (ROV) thereby achieving operational desired effects. The method assigns required behavior (the way that machines or systems operate or interact) to the systems as described by the use case. The process iteratively allocates behavior to smaller system elements (products, services, classes, objects, etc.) while optimizing and identifying reuse opportunities.
The object-oriented method and associated UML tools provide object decomposition focused on operational objects and generalization (inheritance). This practice creates a flexible, loosely coupled interdependent web of elements with inherited properties and relationships – significantly reducing maintenance problems and issues. In addition, well-designed object-oriented tools provide an architecture environment where multiple architecture teams can share visionary process consistency, architectural artifacts such as use cases and classes while managing the evolution of the architecture over time.
|
UML describes the system behavior |
The UML describes the system behavior at its surface from the user’s perspective by explicitly representing operator and inter-system dialog. The method organizes functionality along generalization-specialization lines, promoting process consistency and product line development. The ROV focused method pays special attention to component interfaces and system behavior while leaving the design space open for designers and keeps user behavioral needs foremost. This method lays the foundation for direct object-oriented development activities. In short, structured analysis emphasizes process and functions while object-oriented analysis emphasizes system behavior using objects.
Due to the significant nature of these differing architecture approaches, organizations should not attempt to commonly store both structured and object architecture artifacts in a single data structure rather focus on storing and sharing elements necessary for integration (i.e., focus at the interfaces of the architecture and the services they provide). Architecturally, we should not be concerned about the internal workings of other architectures outside our enterprise, rather the operational services they provide and the operational effect produced. Stored and shared architecture data should focus on services and interface descriptions, which describe how to access these services. Architectures are continuously on the move; similar to software practices, we produce interface mechanisms to insulate the internal workings from the implementation. Therefore, it is at the interface that we must describe, document, and share architecture elements.
Moving Toward a SOA Solution
A significant part of our proposed solution is to engineer operational processes such as mission threads from a service-oriented perspective. It has become commonly accepted that service-oriented architectures (SOA) are the desired end state; however, what services are required? How do you evolve these services knowing they directly support user needs? How do you prioritize service development? How do you recognize the reusable nature of a service? Who are the customers requiring services and what are their priorities? We will demonstrate a process that applies an object-oriented analysis and design (OOAD) system engineering approach to answer these questions while developing enterprise architecture useful in modeling and simulation as well as capability-based planning (CBP).
|
We Understand how to Organize Services |
Not unlike the warfighter organizes the way they fight, we believe an acquisition organization should organize to successfully implement a SOA framework. The attractiveness of a service-oriented perspective is that you can break each layer of the model into individual, independently managed functional areas, yet they all come together during execution. Because service-orientation infers a conceptual description of a the structure of a system in terms of its components and the services they provide, without regard for the underlying implementation of these components, services and connections between components, each layer stands independent of the other. With this thought in mind, to achieve a service-oriented architecture, we should evolve our organization with the appropriate authority and responsibility to achieve this objective. Organizational considerations should include:
· Operational Architecture – UML Use Cases define the operational architecture by identifying the things the system must do, and how to do it – the operational architecture captures the business rules. The use case must capture performance needs as well (in context of its use). It determines reuse from a business perspective and defines operations and support activities by encapsulating operational patterns of behavior – essentially modularizing operational process for mission thread development. We refer to these as business services. Because it’s at the base of our SOA model, it’s the foundation for portfolio and knowledge management. Governance belongs in this layer as well, because the architecture is used to constrain process while adaptations can occur using specialization when appropriate making the architecture adaptable and extendable. Another important value of the operational architecture is its ability to vet functional responsibility among organizational elements of the enterprise. Also important is a process that captures architectural behavior early from a role-based perspective to deal with political and rice-bowl challenges. Once the roles of the enterprise are understood, organizational considers are easier to obtain buy-in. All other service layers are realized from this layer of the model – essentially this layer of the architecture is the governance view.
· Common Operating Environment – Builds and creates common infrastructures such as networks, sensors, communication components, CPU hardware, standardized servers, enterprise service buss, and standardized configurations among others. The infrastructure provides the environment from which developers combine business and software services to create useful user applications realizing the UML Use Cases in the Operational Architecture. Performance measures are best performed in this layer of the framework using the Operational Architecture as the guide. The Operational Architecture captures performance requirements in the use case when operationally significant.
· Enterprise Database – Defines data schemas, common definition of data, and creates and maintains the services to access information. It leverages and implements the operational data needs (logical data model) defined by the Operational Architecture layer.
· Common Services – This layer includes government and commercial applications to include automated office environment applications, and management of net-centric enterprise services useful to the enterprise. It creates the software environment form which to operate. The Common Services layer may include many other “sub service layers” such as common message handling, office automation, among others. Generally, this layer manages software service components.
· Application Development – Involves special application needs not commercially available or possibly customization of COTS/GOTS products with plug-ins or special software wrappers. Web application development would fit in this category.
In order to migrate to SOA, we must leverage the mission or operational need as foremost and implement an approach that uses the operational architecture as the primary framework from which we derive all other frameworks. To be success, we must build our service frameworks using a common lexicon with differing levels of abstraction whereas one layer builds on and traces to the other. Finally, we require an approach where all architecture teams (i.e., operational, database, common services, and applications development have visibility and constraints (governed) by the desired goal. There is a way!
Developing a Service-Oriented Operational View
|
Employs Proven Industry Best Practice |
Serco developed a repeatable, trainable process to develop the service-oriented operational architecture perspective using the UML. A summary of our process follows:
1. Establish Vision and Mission - Through effective group collaboration, we establish the overall objectives of the architecture, its purpose, boundaries, goals, and mission. Over the years, we’ve learned the importance of collaboration by determining the optimal audience size and attendee required expertise – we apply effective communication skills such as congruent sending and active listening. We don’t just train our architects to be technically proficient – we train our architects to be skilled communicators.
2. Determine Enterprise Boundaries - Using a Serco developed UML Context Diagram, we determine the consumption and production of important enterprise objects (typically data), the responsible interfaces (actor) and the responsibility (role) of the interfaces. Our interface descriptions are independent of technological considerations; rather, the focus is on what needs to be done and what information is required. Actors can therefore represent of both people and systems from a role perspective. We use the resulting input/output data entities to determining our value chain UML Use Cases because the context diagramming exposes important information useful in UML Use Case identification.
3. Identify Enterprise Use Cases – Once we identify important input/output data entities using the Context Diagram process, we place action (verb) on important objects (noun) in the form of results of value (ROV) Use Cases. This activity is useful in establishing the responsible roles (actors), and the scope of the activity. Important enterprise boundaries and interfaces are clearly visible and understood when the use case reaches maturity.
4. Detail Enterprise Use Case - Using a UML Sequence Diagram, we determine service responsibility among the roles (interfaces) in the environment as discovered by the Context Diagram. This is the first service-oriented perspective and identifies manageable interface classes. UML Activity Diagrams encapsulate the Sequence Diagram elements and establishes the flow of control between Use Case activities. The enterprise analyst can document information and its state (initial, reviewed, approved, etc.) as it flows through the operational process. This view identifies important business rules as well.
5. Develop Logical Data Model – Iteratively, while detailing the UML Use Case, we develop the information requirements in the form of classes, their attributes, and class relationships. This spiral development technique evolves the Logical Data Model (LDM). Enterprise entities are stored in LDM libraries and reused in future UML Use Case development. In time, the enterprise architects develop a clear view of information needs and how information elements relate to each other. This is a proven technique and is where object-oriented gets its name. The focus is always on the importance information (objects) as it supports the overall objective of the enterprise.
|
OOAD Provides Integration Capabilities |
In the end, the enterprise establishes a clear understanding of the interfaces required to achieve organizational objectives. These interfaces define the communication boundary between two entities, such as a piece of software, a hardware device, or a user. It generally refers to an abstraction that an entity provides of itself to the outside. We must successfully manage required and provided interfaces to achieve enterprise architecture objectives; therefore, our approach exposes important interfaces in a manageable service-oriented framework.
Significance of OOAD
Our award winning object-oriented analysis and design (OOAD) approach solves many problems the DoD has been struggling with for many years – the ability to manage important interfaces of the enterprise while identifying the important results these interfaces provide. We understand how to build value driven models that identify enterprise interfaces while placing the interfaces in the context of their use. We apply industry best practice techniques to identify important interfaces and we perform OOAD analysis to determine redundancies, gaps, or technology shortfalls. Our UML approach allows management of the interfaces by packaging them in logical groupings for management purposes such as contractor development responsibilities or physical deployment. Our models include the ability to package and manage other service models containing mission threads, information models, and completed and planned services all in one integrated UML framework. In essence, our approach provides a standardized service-oriented method to assist in portfolio management of the enterprise. Using this method, the architect captures performance metrics directly in context of the prescribed capability. Managing interfaces in context of the prescribed UML Use Case provides portfolio managers the ability to understand and prioritize developmental investments. For example, using our OOAD approach, the architect can easily identify business services that are frequently used and therefore a candidate for process improvement through either material or non-material solutions. We think about business processes in terms of a service with functional responsibilities clearly defined to include the consumption and production of information elements critical to logical data model development. Finally, the Boeing Corporation recognized our technology breakthrough when they awarded Serco Technology Suppler of the Year in 2007.
Using our OOAD method, the enterprise realizes a capability driven service-oriented framework that is modular, loosely coupled and completely re-usable. These architectures help teams communicate effectively, precisely, rigorously, and at high bandwidth; it drives system development achieving architectural objectives; it accomplishes enhancements more quickly than earlier enhancement efforts of similar functional size because of growing architectural reusability and team agility.
Due to the componentized nature of this approach, we’re employing the Open Source configuration management tool Subversion (SVN). SVN allows us to unify distributed framework projects across the enterprise. Architects can therefore create custom views using the service framework important to their particular need without loading all architectural elements of the entire enterprise. Our object-oriented approach adopts the same techniques and practices commonly used by the software industry where code sharing and configuration management is instrumental to any large application development. The nature of the tools that we use allow check-in, check-out techniques to prevent walking on other architects’ work and ensuring baseline control to allow corrupted elements to be rolled back to previous releases. These tools use the principals of fragments where each fragment can individually be configuration controlled using off-the-shelf commercial configuration management applications such as SVN. Our configuration management approach is relatively straight forward and a common practice used by industry.
Our UML Service-Oriented Framework
|
One Lexicon for All Service Layers Increases |
When we framework our operational capabilities from an interface or service-oriented perspective, the UML Use Case becomes the steering wheel or forcing mechanism to drive what it is the system is suppose to do. After we understand and agree on operational service objectives only then can we effectively define and componentized services. What we are saying is that a framework is a good idea; however, servicing who, where, and for what purpose? From this viewpoint, we believe the Operational Architecture captures the desired capabilities as the most important reference model of them all. Finally, we derive our Operational Architecture from a service-oriented perspective; otherwise, its framework has little value to the overall framework approach because it lacks traceability from an interface perspective – essential for the governance prescriptive.
We build our service-oriented framework on the underlying understanding achieved by the UML operational architecture. Our UML business service models define the mission and capture desired capabilities realized by operational and system nodes as well as system components. In the end, we define operational capabilities from domain, enterprise and other foundational services such as net-centric enterprise services all frame-worked using the UML. Due to the high emphasis of interfaces of this approach both operationally (mission activities) and its realized implementation using UML Sequence Diagrams, the UML Use Case model acts as the steering wheel (portfolio management) to ascertain gaps and overlaps while assisting the decision maker in establishing developmental priorities (i.e., determining what gets the most bang for the buck).
We can’t express more the importance of a service-oriented operational view, because without it how can one determine the common operational services important to the success of the enterprise? With that said, you could employ a perfect best practice conceptual framework yet still fail on its implementation.
Mission Thread Development
From our experience, one of the biggest problems with architecture is the ability to vet the architecture with the non-technical or non-architect. Wrestling with this concept for more than a decade, we’ve developed an architecture animation capability that visually presents the architecture and its underlying service framework in a 2-dimensional (2D) visualization. Our specialized tool actually executes the UML architecture to verify the architecture’s functionality and validate with mission stakeholders the correctness of the result or effect. This capability is unique to our team’s approach. In the end, our method delivers a complete concept-to-code framework.
Another significant issue we’ve been challenged with is the ability to realistically render business models from a service-oriented perspective into 3-dimension (3D) simulations with analytical rigger. Today’s modeling and simulation tools provide great “eye candy” on the surface of the simulation; however, they typically lack a useful architecture foundation from which to control and drive system development. We propose an exciting solution using commercially-off-the-shelf products such as IBM’s Rational Software Architect (RSA) and AGI’s analysis software for land, sea, air and space (also referred as STK) and we believe that there is significant value in integrating these tools.
|
We Make Architecture Understandable |
RSA is a UML tool that provides a service-oriented framework to model business process, software services, system models, and ultimately manage and generate software code. These tools employ a XML Metadata Interchange (XMI) (UML stored in XML) foundation; therefore, data mining the architecture is relatively strait forward. We’ve developed the code to tap into RSA’s communications interface to data mine the architecture directly. Serco’s vision has always been to develop a single environment to develop operational concepts driven by vision and mission, their underlying service frameworks, and ultimately the systems and code that implements it in a 100% traceable way. However, our vision’s primary problem is that UML models are static making verification and validation of architectures difficult due to the inability to impel the model into a real world simulation depicting the environment described by the architecture. We’ve successfully demonstrated executable UML for 2D visual models; however, these visualizations lack environmental feedback and other process stimuli such as the physics of the environment (i.e., range fans, drag, speed, orbital parameters, etc.) as objects move through the process. However, if we develop a way to feed a tool such as STK (Analytical Graphics, Inc. analysis software for land, sea, air and space) with service-oriented business or operational models, we can join the strengths of both tools. The UML provides a basis for interface and development management while STK provides the analytical rigor to analyze the effects of the physical environment (i.e., gravity, surface drag, geography, facilities, speed, etc.). The concept offers a new revolution in modeling and simulation of DoDAF-compliant architectures!
Based on our discussions with Analytical Graphics, Inc. (AGI), we believe this concept is fully achievable. To test our theory, we manually used one of our service-oriented business models to create an STK simulation with total success. However, investment is necessary to achieve the automated solution where UML service-oriented process models drive true simulations with analytical rigger. We believe this is a significant breakthrough in technological because the underlying architecture provides many other uses such as capability-based planning, services collected in a common lexicon, training, configuration management, and concepts driving code development all in a single standardized lexicon. Using our service-oriented approach, we believe the enterprise achieves the capability to employ on-demand use of existing assets with the ability to extend or expand their original use; deploy capabilities quicker; and develop mature enabling elements. Finally, our approach identifies business practice to inform the enterprise on potential optimization opportunities to be more responsive for each mission.
Spirally Evolving to Service-Oriented Architecture
|
Provide a Proven-Effective Spiral Evolution |
Our UML models apply industry best practice to evolve stovepipe systems into an integrated capability using proven architecture process based on service-oriented techniques. Using effective collaboration techniques, state of the art architecture laboratories, effective training and mentoring for both new architects and clients, we model the business process with emphasis on important information needs. We identify the interface points important to the operating environment (responsibilities within and outside the enterprise). The identified information needs lay the foundation for logical data model development using object-oriented DoDAF logical data models (class diagrams). Our class elements visually depict information attributes as required at the relevant interface point supporting the operational responsibility. Our service-oriented operational analysis more easily identifies operational patterns and therefore the most frequently used operational processes – it identifies reusable processes across the enterprise valuable for consolidation to a single implementation. We believe the architecture is the blue print to success and therefore it must reside in one standardized service-oriented framework, which the UML provides.
On the surface, this may appear as an undoable challenge. However, we’ve learned how to apply these solutions one-mission thread at a time. Overtime as mission threads mature in the model, reusable process exposes itself due to the component nature of our UML Use Cases. We store our UML Use Cases in logical packages allowing architects to discover and reuse process when appropriate. Infrastructure, enterprise data, common services, and applications realize our UML Use Cases through collaborations on sequence diagrams creating a seamless service-oriented environment. The future allows the architect to create new mission threads from existing process (to include its underlying service implementation) and more quickly identify gaps to the desired effect leading to recognition of required new UML Use Cases.
A Case for an Enterprise Architecture Center of Excellence
Successful tools and processes in themselves are not sufficient to achieve a complex architecture undertaking. A successful architecture team requires an architecture infrastructure to evolve an enterprise model leading to the desired outcomes the architecture provides. An Enterprise Architecture (EA) Center of Excellence (COE) provides an environment where an organization can concentrate expertise and centralize support to architecture and business process reengineering efforts wherever stakeholders may be located. Building a UML modeling team with the necessary skills and resources from scratch in a new location can take as long as two to three years depending on the availability of a skilled staff. It’s also important to be successful at training and retaining quality people. In addition, a successful architecture staff must include Senior Principal and Principal Enterprise Architects with Object Management Group (OMG) UML Professional Certifications practicing the object-oriented trade in excess of five years. Once in place, implementing an architecture project using an EA COE shortens ramp-up time significantly. In essence, an experienced staff begins work from day one using existing architecture expertise and infrastructures – reducing the time required to train and mentor a capable staff for any given effort. Finally, it’s important to train less experienced client site Operational Analysts with minimal architecture skills to provide the necessary operational analysis and deliver preliminary products to the EA COE for base-lining, configuration management, and application of the architectural discipline.
|
Requires an Architecture Center of Excellence |
Because architecture is a very collaborative endeavor, we emphasize facility considerations. To be successful in developing use cases, architects collaborate and mentor in architecture laboratories properly equipped with large visual displays, computers, and controlled data access points. The large displays are necessary to observe all views of the use case and the many data sources (concepts of operations, documents, and other information sources etc.) sometimes used to understand the required behavior (i.e., use case description) being modeled. A successful architecture environment allows architects, subject matter experts, and stakeholders to collaborate on the architecture and agree on the optimal solution. We hesitate to consider these architecture laboratories optional – they have proven to be so productive that we built six laboratories and they’re constantly in use. We also supplement in-person sessions with Web-based conferencing to reduce travel and vet architectural elements with stakeholders when required.
In the end, stakeholders achieve a fully integrated environment, distributed effectively across the enterprise where responsibilities for success are divided in a service-oriented way. The underlying architecture-based environment becomes the foundation for capabilities-based planning and ultimately portfolio and knowledge management.
Using SOA for Capability-Based Planning
|
Our Service-Oriented Models Become a |
We’re the leader in service-oriented transformation and we are experts at leveraging existing architectures in any form and reshaping them into a service-oriented perspective. We exploit our well-documented process to validate and expand existing reference models, analyze requirements against mission needs, and populate the future models in a well-controlled configuration managed environment. Our data mineable architectures provide a service-oriented environment supporting well-managed and discoverable architecture framework using UML packaging mechanisms. In the end, the underlying environment provides the basis for portfolio management. We’re currently applying our architecture process for many DoD organizations with resounding success. Using our approach, our clients are succeeding in capabilities-based planning using our UML architectures as a portfolio management tool.
Using an OOAD approach, the enterprise realizes a capability to model the entire enterprise to include simulation using a virtual service-oriented framework useful in developing road maps, Initial Capabilities Documents, enabling concepts, cost plans, Joint Capabilities Integration and Development System (JCIDS) architecture views and documentation, Concept of Operations, and much more.
The UML provides an industry standard framework to model, store, collaborate and communicate the vision of the enterprise. Moreover, the process works! If it's working, it is helping teams communicate effectively, precisely, rigorously, and at high bandwidth. If it's working, it is driving systems development achieving architectural objectives. If it's working, it accomplishes enhancements more quickly than earlier enhancements of similar functional size because of growing architectural reusability and team agility. If it’s working, it effectively deals with the complexity of a large enterprise.
|
We Develop Industry Standard Frameworks |
One of the primary reasons an enterprise employs a service-oriented architecture is to deal with and reduce complexity. We believe this begins by exploring the service-oriented operational perspective. An object-oriented operational business service model provides a basis to examine and understand the cross-mission nature to operations to eliminate redundant capability development. If a mature business process exists, why not reuse it along with all its underlying implementations.
Due to the integration nature of our approach, Capability Command Leads can develop Capability Development Documents much quicker than traditional means. In addition, once the integrated architecture is mature, it’s much easier to logically group functional responsibilities necessary to ensure CCDs and other related support documentation does not overlap in prescribed capability need descriptions. In fact, much of the documentation needed to develop requirements documentation can be data mined directly from the architecture!
|
Our Models Provide a Framework for Portfolio |
Bringing it all Together
Using our service-oriented UML models as the basis for CBP and portfolio management, we data mine our architectures to perform Functional Area Analysis, Functional Needs Analysis and Functional Solutions Analysis across the enterprise. Visualization of the model ensures the accuracy and completeness of the architecture through CONOPS validation and verification through the non-technical using our UML animator. As the enterprise spirally evolves and assigns organizational responsibility of operations, infrastructure, enterprise data, common services and applications, the UML architecture becomes the foundation for JCIDS, Planning Programming Budgeting and Execution (PPBE) and the Defense Acquisition System (DAS). The architecture enforces the vision to determine what is needed, what can be paid for, and what can be done in a policy manageable framework while providing a completely defensible requirements baseline.