My last post on the Composable Enterprise gave an overview of Jonathan Murray’s manifesto. While this is leading edge stuff, it is by no means new. We’ve been aiming for composable architectures for many decades now, going back to DCE and CORBA and perhaps even earlier. This speaks to how difficult the challenge is and how our approaches change with lessons learned from previous attempts.

Perhaps the most successful composability framework ever is COM, but reliably scaling this beyond the desktop to the enterprise and the world (one of the aims of DCE and CORBA and WS-* and…) is our ongoing mission.

MITRE Corporation is a huge US government funded organization that looks after federal research, development and integration—usually defence related. Their Systems Engineering Guide is a broad compendium of knowledge and practice that they’ve brought together from their internal subject-matter experts. When perusing this recently I was immediately drawn to the section entitled “Composable Capabilities on Demand” (CCOD).

While I wouldn’t automatically refer to a federal government organization as a source of innovation, there is nothing here I disagree with and it’s interesting to see how these concepts are being trialed and embraced in this environment as a way of achieving value and agility. The CCOD page is a short read and well worth the effort. I thought I’d just pick out some of the salient points here.

CCOD is a design concept to enable the rapid development of new capabilities by combining services, data, and existing systems to respond to a new situation or mission.

(Despite my pacifist nature, I love the military jargon…very top-gun. Reminds me of some of the people I’ve worked with in Baltimore and Denver in times past. And I sometimes feel like a “combat coder” under fire.)

Key to CCOD is “interoperability” which is facilitated by common data formats that they call “loose couplers”. But beware of our traditional concept of common data models: “Experience to date suggests that a minimalist approach to loose couplers is a key principle. Global, complex data standards may prove problematic, due to the large investment in parsing/integrating/adopting them” (my emphasis added).

An important part of CCOD is that it is aimed at end-users, not developers. To make this possible the CCOD capabilities must be:

• User-facing: they must provide a useful business function.
• Rapidly integratable: ideally by the end-user.
• Quickly adaptable: to unanticipated tasks on hand.
• Assured: from the perspectives of trust, security, versioning, validation.
• Integratable: with existing business processes and systems.

The remainder of the CCOD entry goes through a list of “best practices and lessons learned” which I’ll summarise:

• Favor the small and reusable: “light weight” assures ease of adoption and integration across a variety of users and uses.
• Make components discoverable: through a “marketplace” or “app store”.
• Develop components with an understanding of the end-user: experience is leaning toward a design-first concept for components.
• Focus on reuse: aim for reuse and use existing open source tools that have adoption momentum and are adequate to the task.
• Strongly consider RESTful architectures: which has proven to be robust and flexible enough for quick development and integration of components.
• Strongly consider loose couplers: using data representation standards and service descriptions to ensure components are independent of each other.
• Explicitly design component granularity: pick the right abstraction level and test it with the user population.
• Plan for integration early: use system architecture and interaction diagrams to avoid nasty surprises in the integration phase.
• Emphasize documentation: make it easy for end users to find and use the components.
• Separate visualization from functions: expose data in machine readable formats that can be interpreted by a seperate visualization layer.
• Accomodate dependencies: document dependencies and design to mitigate component failure.
• Scope the use of CCOD: have well-defined and realistic use-cases that can be scoped within resource and time restrictions.
• Seek operational context: some use-cases aren’t suited to CCOD, e.g. realtime targeting (or an alternative example, high-frequency trading).
• Build from existing components: discover and integrate existing components, use adapters for “non-composable” systems of record. Decompose large systems into smaller units for composition.
• Verification/Validation: test components independently. Document tests so users can understand component limitations.

Overall, sounds like reasonable advice.