Engineering Information-Intensive Enterprises
Definition: An enterprise is a network of interdependent people, processes, and supporting technology not fully under the control of any single entity. An information-intensive enterprise is one for which successful operation substantially depends on networked information systems. Engineering an information-intensive enterprise concentrates on managing uncertainty and interdependence in an enterprise, and it involves engineering both the enterprise and the systems that enable the enterprise. Engineering an information-intensive enterprise is directed toward building effective and efficient networks of individual systems to meet the objectives of the whole enterprise.
Keywords: architecture, change, composable, design patterns, information-intensive, innovation, mission assurance, open systems, uncertainty
The success of our sponsors' organizations increasingly relies on information. If the right information isn't available when needed, the missions and outcomes of the enterprise will be less effective, efficient, or successful.
An enterprise has many components and information that must come together for mission success. Data, business rules, applications, communications, and sensors need to be created or composed into capabilities within the constraints of the enterprise's architecture(s), designs, existing systems, and mission assurance requirements. Here are a few examples:
- For homeland security, communications capabilities must support the needs of first responders and state, local, and tribal partners.
- In the DoD, cyber security threats require careful consideration and close examination of open capabilities and emerging technologies, such as social networking, before employing them.
- In air traffic management, the need for public trust may drive the business rules associated with free flight and use of unmanned systems in the national airspace.
- For modernization efforts like those at IRS and VA, questions arise about how and when to insert new technology and capabilities in light of the readiness of the operational organizations to absorb them and their associated new processes and procedures.
Articles under this topic are intended to help MITRE staff in engineering information-intensive enterprises.
- Architectures are used by and across our customers for a variety of purposes—to support understanding of operations, help with system design and implementation, and provide basic building blocks for enterprise capabilities. A federated architecture helps deal with the magnitude and complexity of engineering cross-enterprise needs to enhance overall mission effectiveness. The article "Architectures Federation" discusses howfederated architectures enable local innovation, enterprise integration, and evolution across major portions of an enterprise—many of which may be enterprises in their own right.
- Design patterns in software are not concrete pieces of software, but a kind of stencil of best practices applied in certain situations. MITRE systems engineers (SEs) are likely to encounter and use them in developing or reviewing interfaces between system components or, at a higher level, across system boundaries. The article "Design Patterns" describes basic approaches, best practices, and lessons learned in using these patterns in engineering service-oriented environments and interface standardization activities.
- The article "Composable Capabilities on Demand (CCOD)" describes a new and evolving strategy to enable the rapid piecing together of capabilities to meet end users' needs, in some cases by the users themselves. CCOD is in the style of many Internet tools that enable the rapid application of various services to data or informationto compose a "user-defined" or tailored view/perspective to satisfy their needs.
- Open systems approaches enhance the ability to rapidly create capabilities in information-intensive systems. The article "Open Source Software (OSS)" provides an historical perspective on OSS, describes the rapidly changing view of OSS and its relationship to engineering information-intensive enterprises, highlights government interest in and use of OSS, and concludes with a comprehensive and detailed set of best practices and lessons learned in applying open system techniques and using open source software.
- MITRE systems engineers should understand the legal requirements that apply to federal agencies' collection, use, maintenance, and disclosure of personally identifiable information. The article "Privacy Systems Engineering" provides guidance on how privacy must be built into the systems engineering life cycle and how technology can be leveraged to protect privacy.
MITRE SE Roles & Expectations: MITRE systems engineers are expected to develop enterprise solutions that balance local innovation with global innovation and evolution. They develop solutions that (a) provide customized innovations to meet end-user local needs, and (b) interoperate with, respond to, and co-evolve with an environment that itself is constantly changing.
Best Practices and Lessons Learned
- Information as Capital. Treat enterprise data and information as a capital resource that has value over time. Emphasize the importance of a data strategy in your work.
- Data Interoperability. Adopt the view that data interoperability should be engineered to ensure that cross-enterprise capabilities are realized.
- Be Attuned to Enterprise Cycles. There are long- and short-term customer cycles. The former includes activities like budgeting, requirements, contracting, and implementing. The latter includes responding to urgent operational needs. Understand and differentiate between them, and adapt systems engineering to them.
- Consider Capability Longevity. Understand the likely longevity of the capabilities that users need. Adapt your perspective and systems engineering approach to this aspect of the capabilities you engineer. A capability might be required for the immediate situation/environment, but then not be needed for the next crisis, or ever again. In a crisis, consideration of capability evolution might not be a critical part of the systems engineering analysis, but consideration of future use should not be completely set aside. For example, a design pattern could be used to create an immediate capability that, at the same time, facilitates use for future crises. A composable capability strategy can enable components to be created and be "on the shelf" to support future situations. Open source capabilities can provide a foundation for "immediate use."
- Don't Throw Away "Throwaway" Thinking. Many customer developments stress that everything must be able to be reused by others (and this has intensified in the service-oriented world). While this is often the case, there may be times when the prudent course of action is to build a faster, cheaper, throwaway capability. Understand the value of reuse within your enterprise and by others, but also understand there are situations in which building a throwaway version is the better course of action.
For more information on the Systems Engineering Guide, or to suggest an article, please Contact Us.