Open Source: The Dominant Warfighting Doctrine of the 21st Century

Open source software offers the promise of a revolutionary transformation in defense, intelligence, law enforcement and government technology at a cost and pace that satisfies the competing requirements of shrinking resources and constantly accelerating global operations.   While this technological transformation is emphasized by engineers and developers within industry and the acquisition community, it is often perceived as tangential to those with an operational focus. 

This apparent dissonance between the acquisitions and operational communities is caused by the broad nature of the open source phenomenon:  Open source refers as much to a cultural perspective as it does to a technology model.  However, the gulf separating the two sides isn’t as wide as it may appear.  For the acquisitions community, open source technology enables the rapid insertion of new and improved capabilities.  For the operators, open source culture enables the achievement of a doctrine and force structure for self-synchronizing operations.  The cultural and technological synergy of open source is the catalyst for, as David Alberts and Richard Hayes put it, pushing “power to the edge.”

Open Source Culture

One of the best expositions of open source culture is Jason Hibbets’ The Foundation for an Open Source City.  In addition to being a compelling call to arms for open source advocates, the book offers a pragmatic exposition of the characteristics necessary for an organization to reap the benefits of open source culture.  Open source, as Hibbets points out, encompasses more than the selection of a software licensing scheme.  Open source is about empowering both creators and users to determine the most effective solutions to a problem and at the same time, empowering them to add experiential value to those solutions derived from their own knowledge and experience.

The characteristics of an “open source city” are neatly summarized in five bullets:

•    Fostering a culture of citizen participation;
•    Having an effective open government policy;
•    Having an effective open data initiative;
•    Promoting open source groups and conferences; and
•    Being a hub for innovation and open source business.

It’s worth a brief look at each of these.

Citizen – and for our purposes, that can be read as “user” -  participation is critical to the rapid development of innovative solutions.  Broad citizen participation allows issues and challenges facing a political entity to be placed  before its constituency.  More importantly, it allows for solution concepts to be drawn from the constituency – a much larger pool than government.  The contemporary buzzword for obtaining ideas by casting challenges before a mass of people (especially from an online community) is “crowdsourcing.”  It’s really a much older concept.  In The Cathedral and the Bazaar, open source evangelist Eric Raymond called it “Linus’ Law,” in honor of the originator of Linux, an open source operating system, Linus Torvalds.   Linus’ Law says ““Given enough eyeballs, all bugs are shallow,” applying the principles of broad enfranchisement and participation to problem solving.

Open government policies are designed to improve transparency (and, concomitantly, trust), access to public information and coordination between government (and other public sector entities) non-profit, the private sector and the citizenry.  They do so by emphasizing distributed review, inclusiveness and broad and diverse participation.  Such policies are often tangibly expressed as publicly accessible web portals with open data, web and mobile applications for visualizing and using the data and links to stakeholder organizations.

Open data initiatives are about making data both publicly available and useful.  Making raw data sets accessible doesn’t help the vast majority of users.  True open data initiatives provide mechanisms by which users can consume the available data.  These may include visualization tools, search engines and web applications that enable users to derive benefit from the data.

Open source culture is grass roots in nature.  In order to thrive it requires an environment in which stakeholder communities are encouraged and supported.  Support means a number of things, including providing physical space in which to conduct activities and meetings, an environment that encourages a continual influx of new ideas and concepts, using official channels to disseminate information about and of relevance to the open source communities both internally and externally and, of course, financial support.  The nature of this support is important; it should be enabling rather than prescriptive if the broad participation that empowers open source is to be effected.

The last characteristic, that of being a hub for innovation, is really the result of the other four.  When a political entity enables open source with the encouragement of broad participation, enactment of governance policies, open data and material support, many groups with a common vision, but a diversity of approaches to realization, are brought together.  The result is that only broad guidance is necessary to create the desired effects.

Power to the Edge

Power to the edge is a command and control philosophy initially articulated in the early 21st century by the US Department of Defense Command and Control Research Program (CCRP).  Command and control (C2) is, in US doctrinal terms, an organization’s ability to exercise authority and direction over subordinate components to achieve mission objectives.  C2 is achieved through the interplay of personnel, equipment, communications, facilities and procedures that enable a commander to plan, coordinate and control forces during operational activities.

Power to the edge philosophy emphasizes a decentralized form of C2 where the commander’s role shifts from one of providing prescriptive oversight (i.e., a goal, an operational solution and direction as to how to achieve that solution) one of providing general guidance and enabling support.  The concept is not new; indeed, the German Army has emphasized what it called Auftragstaktik, or mission-type tactics, since the early 19th century.  Auftragstaktik as a doctrine features individual initiative, independent decisionmaking and encouraging subordinate leaders to reach tactical decisions on their own accord in furtherance of a general command intent.  The commander’s primary roles are to provide an overall vision of the objective end state and to support the force, giving virtual autonomy to the subordinate commanders in achieving her intent. 

The key difference between Auftragstaktik as practiced by the German Army in two World Wars and Power to the Edge as envisioned by the CCRP is the addition of shared situational awareness, enabled and supported by robust networking,  in both superior-subordinate and peer-to-peer relationships.  Shared situational awareness between peer organizations engenders clear and consistent understanding of the commander’s intent, the timely exchange of relevant and high-quality information, a demand for competent participation at all levels and trust in and between the information being exchanged, subordinates, superiors, peers and technology.  The result is that robustly networked organizations are able to self-synchronize, dramatically reducing both the need for command intervention to cope with the vagaries of the battlespace and the time required for the force to make sense of and respond to new operational stimuli.

For Power to the Edge/self-synchronization to work, the subordinate organizations must be technically enabled and procedurally empowered to fully engage in the supply, consumption and enhancement of battlefield information.  At the same time, the commander must create an environment where all members of the community are aware of the overall mission goals, the intent is clearly communicated and where openness and trust between the command and subordinate units is fostered.  Part of this environment is ensuring that, within relevant operational security constraints, all subordinates have on demand access to the tactical and intelligence data held at the command.  Additionally, the commander needs to ensure that subordinate units have the necessary material and logistics support (i.e., equipment, training, etc.) to participate effectively in Network-Centric Warfare (NCW), and to nurture a shared mindset that encourages subordinates to exercise initiative and find creative solutions without adverse impact for imperfect decisions.

The last requirement is critical.  Prudent risk-taking is an element of initiative, creativity and innovation.  Power to the Edge demands that commanders encourage their subordinates to exercise tactical initiative, while recognizing that errors and reverses will occur. The sum of successes derived from the exercise of battlespace initiative, the theory states, will overcome the occasional setbacks. A "zero defect tolerance" command philosophy discourages initiative and stifles innovation.  In the open source and Agile communities, this is called “failing fast,” and is a necessary and encouraged facet of the development life cycle.

A Rose by Any Other Name

Even a cursory familiarity with C2 philosophy shows a striking correlation between Power to the Edge and the tenets of open source culture.  It’s possible, however, to go a step further and make a strong case that open source culture is synonymous with Power to the Edge, which is rapidly becoming the dominant battlefield doctrine of the 21st century.  The table below relates characteristics of an organization that has embraced open source culture with corresponding tenets of Power to the Edge doctrine:

Open Source Culture Characteristic	Power to the Edge Tenet
Welcoming participation by all stakeholders	Ensure that subordinate units are technically enabled and procedurally empowered to fully engage in the supply, consumption and enhancement of battlefield information
Effective open governance policy	Ensuring that the overall mission goals and commander’s intent are clearly communicated and that the command ethos fosters openness and trust between the command and subordinate units
Effective open data initiative	Ensuring that, consistent with operational security constraints, all subordinates have access to the tactical and intelligence data held at the command
Promotion of open source groups	Ensuring material and logistics support so that subordinate units can participate effectively in Network-Centric Warfare (NCW)
Serving as a hub for innovation	Creating an environment where subordinates are encouraged exercise tactical initiative, while accepting that errors and reverses will occur and ensuring that "zero defect tolerance" command philosophies are unacceptable

Conclusion

Open source is more than a licensing scheme for software or a business model.  It is an organizational culture and a management philosophy that leads to efficient and effective project execution, often at a significant savings in time and resources.  With widespread acceptance of Power to the Edge doctrine, open source is no longer a countercultural rebellion against the inefficiencies of large organizations.  Instead, it has matured into the dominant management philosophy of one of the largest and most complex enterprises on the planet.  We can only hope to see industry and government follow suit.

Embracing a Resourceful Information Security Culture

Following the news, it’s difficult to escape a sense that the defense community is mired in a Sisyphean game of information security (INFOSEC) catch-up.  It seems that as soon as a policy is embraced by government agencies and their industry partners, new threats emerge and existing dangers increase in magnitude.  

Reminders are ubiquitous: June 3 saw the opening of Bradley Manning’s court martial.  Manning, an Army private first class, is accused having illegally downloaded and forwarded huge amounts of classified information to Wikileaks.  A week or so earlier, the Washington Post published a report indicating that Chinese hackers had successfully penetrated at least a dozen high profile American weapon systems, including those tasked with critical air defense, battlefield mobility and maritime dominance responsibilities.  The list could go on.

Fortunately, many of the community’s INFOSEC challenges are philosophical and fiscal rather than technical.  As such, they can be addressed by harnessing currently available resources, which, in an era that pits escalating requirements against sequestered budgets, is fortunate indeed.  The remainder of this article discusses four key improvement vectors that will enable the defense community – government and industry - to begin to address looming cyber and INFOSEC concerns, specifically: 

• Acquisitions staffing reform;
• Baked in INFOSEC;
• Automated auditing and monitoring; and
• The use of open source software.

Acquisitions Staffing Reform

Impeccably trained by organizations such as the Defense Acquisition University (DAU), the US Department of Defense (DoD) fields what is arguably the finest team of program managers and acquisition professionals in the world.  These people, who are ultimately coordinated by the Under Secretary of Defense for Acquisition, Technology and Logistics (AT&L) are extremely well versed the art of buying goods and services.  Assisting and advising the program managers are military and civilian experts who are charged with ensuring that the goods and services received are of best value and most use to the end users.

Unfortunately, these advisers, while well versed in operational needs and utility are generally not technical experts with regard to software and computing technology, especially as it applies to cybersecurity or its constituent disciplines such as infrastructure security, application security (AppSec) or malware detection and remediation.  As a result, program offices are placed in the position of relying on the same engineers and developers who are paid to develop systems for technical advice.  The contractors, in turn, may have a conflict of interest between the roles of advisor and solutions provider.

Solving this problem requires a fundamental augmentation to the acquisition community’s capabilities in terms of technical expertise.  Near term resources are available from existing DoD-affiliated expert organizations such as university affiliated research centers (UARC) and federally funded research and development centers (FFRDC).  It is likely that acquisition community will need expand this resource pool (either through direct government hires or through the use of contracted technical validation expertise) to fully represent the technical INFOSEC skill set.  

The silver lining to acquisitions staffing reform is the promise of overall lower system acquisitions costs as INFOSEC gaps are identified and remedied at the requirements level instead of after coding, an important benefit in the era of sequestration.

"Baked in" INFOSEC

The current model for incorporating and validating INFOSEC requirements and capabilities focuses on the tail end of the software development life cycle (SDLC).  While there are some proactive measures, such as the use of approved software tooling or adherence to Security Technical Implementation Guides (STIG) issued by the Defense Information Systems Agency (DISA), most INFOSEC activity takes place after a system has been developed.  

Typically, when a developer completes a new system (or a modification to an existing one), it is submitted for certification and accreditation (C&A) review.  The review includes security validation testing against the required information assurance controls (IAC).  At the conclusion of testing a list of vulnerabilities and mitigations is created, which are then negotiated into actions by the government program manager, the developer and the reviewing organization. 

The fixes are then applied to a completed, coded system, often requiring significant rework, time and expense.  More troublingly, many of the fixes take the form of a security applique, layered on top of the existing system.  These security appliques often compromise the system’s mission utility by increasing operator workload.  Systems featuring this applique approach are also inherently less secure than those that have incorporated INFOSEC mechanisms into their architectures from the beginning. The National Institute of Standards and Technology (NIST) recognized the benefits of designed-in INFOSEC in Special Publication 800-27 Rev A,Engineering Principles for Infomation Technology Security (A Baseline for Achieving Security), which specifies that security should be an integral part of overall system design.

Applying – and validating – INFOSEC capabilities early in the SDLC, at the requirements an architectural levels, not only creates more secure systems, it also cuts down on the expense of rework often necessary to meet C&A guidelines, resulting in more fiscally responsible systems acquisition.  The achievement of “baked in” INFOSEC rests on what we’ll call a “strategic security triad.”  The triad consists of:

• Requirements stemming from authoritative laws, regulations, policies and guidance (LRPG);
• A DoD-wide library of modular, standards-based, approved INFOSEC implementation patterns; and
• DevOps principles of continuous integration and automated testing.

Fortunately for the community, all three legs of the triad are represented by resources that are currently and economically available:  

The DoD is replete with mature, forward leaning INFOSEC LRPG. Typical of these is the Defense Information Enterprise Architecture (IEA) published by the DoD CIO’s office.  The document mandates basic principles of secured access such as assured identity, threat assessment, policy-based access control and centralized identity, credential and access management (ICAM).

An implementation pattern library would include pre-approved INFOSEC tools as well as requirements for what the tools have to accomplish for the system, and how they are to be implemented.  There are many INFOSEC tools currently available from industry.  These include things such as IBM’s Security Framework product line and CA Technologies’ Identity Minder.   

Interesting from a government perspective is the emergence of supported open source products into the INFOSEC space.  These tools offer the promise of open standards, modular design and implementation and enterprise class performance – all with zero acquisition cost.  Typical of this line is the WSO2 Security and Identity Gateway Solution.  This solution integrates four WSO2 products, the WSO2 Enterprise Service Bus, the WSO2 Governance Registry, the WSO2 Identity Server and the WSO2 Business Activity Monitor (BAM) to provide a complete AppSec solution including authentication, authorization, auditing, monitoring, content-based filtering, input validation, throttling, caching and Single Sign-On.  

The last leg of the triad, continuous integration and automated testing, requires tooling that can implement strong programmatic governance.  By requiring all of a program’s developers to use a common, Cloud based development platform that includes automated testing, integration and build tools, both functional and non-functional INFOSEC requirements (such as ports, protocols and services settings) can be validated before a module is accepted for integration into the application’s trunk.  Modules not meeting the requirements are rejected, with a report indicating what the developer needs to address.  As a result, C&A testing is an ongoing, integral part of development, and end-state C&A activities are dramatically curtailed.  An example of such a DevOps platform is the WSO2 App Factory.

Automated Auditing and Monitoring

Among NIST’s computer security principles is the need to implement audit mechanisms to detect unauthorized use.  Implied in this requirement is the need to notify the administration and response team as soon as a breach or other unauthorized activity is detected.  Given the size and scope of system activity and transaction logs, it is necessary to automate this process to achieve the necessary timeliness.  

Essentially, auditing and monitoring is a Big Data analytics problem.  Fortunately for the defense community, industry has been focusing on Big Data Analytics for a number of years.  There are a number of analytics platforms available for this task such as Google’s Dremel, Apache Drill and the WSO2 BAM.  Like the others, WSO2 BAM provides the capability to perform rapid analysis on large scale data sets.  To this, however, WSO2 BAM adds alerting and customizable dashboarding capabilities, which can be used to ensure near-real-time notification of suspect events.  When compared to currently acceptable auditing paradigms, some of which allow for a week or more between manual inspection of security logs, this represents a significant capability improvement.

Open Source Software

The most obvious benefit associated with open source software is cost.  Generally available without licensing fees, the use of open source software makes it much more cost effective to incorporate advanced INFOSEC capabilities than proprietary software.  However, while open source software contributes to lowering a system’s total cost of ownership (TCO) it is not without cost as development and production support services generally require paid subscriptions. 

Open source software has an added security benefit that is particularly compelling.  Specifically, open design and source code enable broad based, detailed code inspection and the rapid detection of both flaws and threats.  The idea that proprietary software is more secure because the source code is hidden just doesn’t stand up to scrutiny.  NIST’s selection of the Rijndael block cipher as the Advanced Encryption Standard (AES) in 2000 followed a nearly three year process in which a number of algorithms were publicly discussed, debated and cryptanalyzed.  In another case, Borland published and widely sold the InterBase database for seven years.  In 2000, InterBase was open-sourced as the Firebird project. Within five months of the product being open sourced, a hard coded backdoor (username “politically,” password “correct”) was discovered.

Conclusion

Strong system INFOSEC is in the best interest of the entire defense community.  While there have been both doctrinal and cultural fits and starts with respect to effective, community-wide policies, a fortunate confluence of technology, development philosophy and leadership exists that can allow the closure of critical security gaps.  As computer security expert John Pescatore noted at the June 4 Kaspersky Government Forum, we need to find the balance between perfect solutions that work, but are untenable and solutions that work and are tenable, but might not be perfect.   Acquisitions staffing reform, baked in INFOSEC, automated auditing and monitoring and the use of open source software are the first big steps toward tenable.

Future Proof by Design: Loose Coupling and Ensuring Long Term Success

Technical future proofing assumes constant change in both operational environments and technology.  The impacts of change are mitigated by emphasizing versatility and adaptability in system architecture.  This tenet applies equally to both hardware and software systems.  By ensuring that system components are modular, and that they interact using standard interface patterns and in a loosely coupled manner, components can be modified or readily swapped for more capable variants across the entire system lifecycle.  As a result, the system as a whole remains functional and useful well past the time when the original configuration has become obsolete.  This article illustrates risks associated with inadequate future proofing and provides an overview of tools and techniques that promote long lasting, future proofed software systems.

The Parable of the Joint Strike Fighter

F-35 C-Variant Testing; courtesy of www.jsf.mil

During a sidebar conversation at the recent DC Open SourceCommunity Summit, a lively discussion ensued concerning the troubled F-35 JointStrike Fighter (JSF) program.  The JSF program began in 2001, with a projected budget of $233 billion and an estimated initial operational capability (IOC) taking place between 2010 and 2012.  As chronicled by Government Accountability Office (GAO) in a report published on April 17, 2013, the program’s price tag is now nearing $400 billion and IOC is not expected until 2017 or 2018. 

During testimony before the US Congress on April 24, 2013, the JSF Program Manager, US Air Force Lieutenant General Christopher Bogdan, indicated that problems with the JSF’s complex softwaresuite created risks to the 2017 IOC date.

The ever expanding numbers and constantly slipping dates do not cast either the defense acquisitions community or industry in the most flattering light.  However, righteous taxpayer anger and legislators’ ire masks what may be the most troubling aspect of the JSF lifecycle. Specifically, the JSF may be operationally obsolete by the time it is delivered to combat squadrons.  In the twelve years since program inception, armaments developments in both the United States and abroad may render the aircraft significantly less effective than planned.

Courtesy www.defenceweb.co.za

In 2010, it was reported that the People’s Republic of China had deployed the Dong-Feng (DF) 21D mobile medium-range ballistic missile(MRBM).  The DF-21D, with a 1,500 nautical mile range, is designed to target and destroy aircraft carriers.  The threat to the JSF’s utility is clear:  The F-35 has a combat radius of approximately 600 nautical miles.  Carriers operating F-35s in a hostile Pacific Rim would have to steam through – and then loiter within – a danger zone of approximately a thousand miles in order to deploy their strike aircraft.

Courtesy www.navytimes.com

More recently, on May14, 2013, the Associated Press reported that, for the first time ever, the US Navy had launched an unmanned aircraft from an aircraft carrier at sea.  The stealthy aircraft, called the X-47B, is capable of speeds approaching Mach 1 (it’s officially described as “high subsonic”), has a range in excess of 2,100 nautical miles, contains internal weapons bays and is expected to serve as the prototype for the Unmanned Carrier Launched Airborne Surveillance and Strike System (UCLASS).  UCLASS is expected to enter service in 2019.  

The UCLASS’ existence raises uncomfortable questions about the JSF:  Why is a relatively short ranged manned aircraft, whose limitations expose expensive and vulnerable capital ships to catastrophic danger necessary when a long range, stealthy, unmanned platform is available to complete many of the same missions?

The fact that the JSF program wasn’t future proofed from an operational perspective isn’t surprising.  It isn’t realistic to expect accurate technological (or budgeting) predictions a decade in advance (the X-47B first flew in 2011).  What is surprising is that the program wasn’t designed from a componentized, modular perspective that would have guaranteed continued relevance and capability.  Instead, the F-35 is a tightly integrated package representing the state of the conceptual art responding to operational concerns of the very early 21^st century.

Software and Future Proofing

The issues and architectural requirements attendant to future proofing aren’t unique to hardware in general or weapon systems in particular.  Many legacy software systems suffer from similar issues stemming from monolithic, tightly coupled designs suited explicitly for one or more specific clearly defined purposes.  Unfortunately, these design paradigms result in heavy sustainment burdens, vendor lock-in situations and difficulties with adaptation.

Fortunately for software acquisitions program managers, industry has evolved architectural paradigms intended to alleviate software future proofing concerns.  Examples of these paradigms are service oriented architectures (SOA) and Cloud computing concepts such as software as a service (SaaS) and platforms as a service (PaaS).  However, at the heart of all of these future proofing methodologies is a design tenet known as “loose coupling.”

“Coupling” is a technical term of art that refers to the degree of direct knowledge that system components need to have of one another in order to interoperate.  Loose coupling is a design tenet that ensures that minimizes dependencies between a system’s components to the least practical extent.  Its objective is to eliminate the impact a change on one component has on the rest of the system.  Limiting the number of interconnections between components through adherence to loose coupling principles brings long term benefits such as easier problem isolation, simplified testing and lower maintenance and sustainment costs.

The extent of a system’s coupling can be measured in terms of the degree to which a component can be changed without adverse effects to the rest of the system.  Such changes might include adding, removing, renaming or reconfiguring components or modifying a component’s internal characteristics or the way it interfaces with other components.  The more readily individual components can be modified or swapped without impacting the rest of the system, the greater the degree of loose coupling.  With respect to future-proofing, greater degrees of loose coupling translate to more efficient and less costly modifications, with shorter cycle times, to account for changing requirements.  Greater degrees of loose coupling equate to greater future proofing.

Loose Coupling Tools and Components

There are many ways to enhance loose coupling.  For example, data exchanges could mandated to use a flexible data format such as XML or JSON that allows subscribers to publish the definitions of how to use the data as a schema.  Another method is to use dedicated middleware that allows for the isolation of system components.  Within the SOA paradigm, there are three widely used middleware tools that promote loose coupling:  The enterprise service bus (ESB), the data service and the message broker.  A brief explanation of each of these is worthwhile.

ESB

The ESB is a software component that provides data transport, transformation and mediation services between interoperating software services, applications and components within a heterogeneous and complex application landscape.  All interactions between system components take place through the ESB, isolating the components from one another.  As a result, changes to a component are confined to the component and any mediation adapters within the ESB that transform the component’s outputs into formats useful to the rest of the system.  All other system components are shielded from the change.  In addition to their integration capabilities, ESBs also provide services such as routing, gateway functionality for messages, services, application programming interfaces (API) and security and monitoring.  Many vendors provide ESB offerings.  Interestingly some of the most capable are also open source, such as the WSO2 ESB, the Mulesoft ESB and OpenESB.

Data Services

Data services are integration mechanisms addressing the challenges of heterogeneous and disparate data stores that underlie legacy application integration efforts.  Rather than requiring a lengthy and expensive data migration and normalization effort, architects can integrate legacy, external and objective data stores using data services that retrieve and expose data as web services or REST resources.  These data services provide loose coupling between the data stores and the rest of the system.  Changes to either a data store or a data consumer are isolated by the data service.

Moreover, the data that data services expose is not limited to traditional SQL relational database management systems (RDBMS).  NoSQL databases, CSV/Excel files, RDF triplestores/quadstores and web page scrapes can all serve as data sources.  Data services can also integrate security concepts such as authentication, authorization, confidentiality, integrity and encryption using open standards such as Basic Authorization over HTTPS, WS-Security, WS-Trust, WS-Secure Conversation, WS-Policy, WS-PolicyAttachment and WS-SecurityPolicy.  Typical of data service implementation tools (and also open source) is the WSO2 Data ServicesServer.

Message Broker

Message brokers sit between components, mediating communication and providing loose coupling by minimizing the awareness that components need to have of each other in order to be able to exchange messages.  Many message brokers also provide temporal decoupling, allowing for asynchronous communications.  At its most basic, a broker takes incoming messages from applications and provides some form of communications mediation, such as:

• Message routing;
• Message distribution;
• Support for both request-response and publish-subscribe messaging.

If these seem similar to the capabilities offered by an ESB, it’s because they are.  Message brokers and ESBs have different technological roots, but have some overlap in the capabilities they provide.  There are, however a couple of basic differences.  A message broker (generally) provides only message distribution capabilities, either in the form of queues (for single consumers) or topics (for event distribution/multiple consumers).  An ESB can work with a message broker or use more direct messaging mechanisms such as HTTP.  Additionally, ESBs generally provide content mediation and transformation capabilities.  Unfortunately, there isn’t an industry standard for where an ESB ends and a message broker begins.  Open source message brokers include the Fuse Message Broker, the WSO2 Message Broker and Mosquitto.

Loose Coupling and Future Proofing

In the end, future proofing is about ensuring that a delivered system is readily adaptable with respect to changing technologies, changing missions and changing operational environments.  There are a number of requirements implicit to adaptability:

• The system must be functionally modifiable such that it can complete missions for which it was not originally designed;
• The cost of modification must be kept to a minimum; and
• The time required for the modification must be kept to a minimum.

Following the chain to its logical conclusion future proofing equates to adaptability equates to loose coupling!  While the F-35 may be both operationally and technically tightly coupled, the wide availability of middleware tools promoting decoupling – many of them open source – ensure that military and government software programs do not have to be.