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 21st
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.
No comments:
Post a Comment