The Executive Perspective
Increase IT Agility while addressing Environmental Complexity and reducing Operational Expenditure.
An impossible dream?
To be Agile, to be Robust, to be Evolvable, applications and the environments in which they run must be highly modular, loosely coupled and yet simple to Manage and Maintain.
What is a “modular application”?
A modular application (also called a composite application) is built from a collection of self-describing modules: the usual analogy being a structure built from LEGO® bricks. The modules are self-describing; meaning they each state what they provide (their Capabilities) and what they need from the environment (their Requirements) in order to offer the desired application interface (API) or Service.
Why is modularity important?
- Modularity makes complexity manageable
- Modularity enables parallel work
- Modularity is tolerant of uncertainty
The constituent modules in a modular application may be treated in isolation, so can be easily patched, updated, refactored, or replaced. The structure of an Application assembled from self-describing modules is also self-documenting; hence code pedigree, environmental complexity and technical debt are immediately quantifiable.
For these reasons the burden of ongoing maintenance is significantly simplified, thereby significantly reducing operational costs. A strategy founded on Modularity is essential for organizations that aspire to be Agile while significantly reducing Operational expenditure.
As environments become increasingly modular, the complexity and nature of dependencies increases. As changes occur, these dependencies are affected. Manual management of these runtime dependencies is both expensive and highly error prone.
Highly modular runtimes are essential, and yet planned and unplanned Change is inevitable. Hence automated management of dependencies, in highly modular environments is essential.
Modularity enables software ‘re-use’. This is true, if and only if, the modules are self-describing and enforce strong isolation between their internal structure and the environment in which they run. Given this, flexible and cost effective business strategies for the sourcing and maintenance of modules can be pursued from in-house, near-shore, off-shore and third party providers.
Clearly an effective Industry Standard is required to enforce inter-operability between software modules sourced from different providers.
Also as modular systems are built to ensure simple maintainability and upgradeability over many years, the modularity standard must be an open Industry Standard backed by a majority of software vendors. This ensures longevity and avoids vendor or community lock-in.
The open industry standard for software modularity is OSGi – this standard is managed by the OSGi Alliance.
The Paremus Service Fabric
The Service Fabric provides the necessary foundations upon which highly modular and therefore agile business applications and systems may be automatically assembled, managed and maintained.
The structure of each application and system deployed to the Service Fabric is self-describing; Governance and Regulatory requirements concerning the auditability of code are therefore automatically satisfied. As each Service Fabric can be authorized to access a federated set of component repositories; modules can be sourced from any combination of business aligned, organization wide, or approved community, third party or open-source repositories.
Planned and unplanned changes, whether in an application or system structure or configuration, or in the runtime environment, are automatically detected by the Service Fabric and it responds in the appropriate manner to ensure that all runtime dependencies remain satisfied. Maintainability, agility and availability are increased, while operational risk and operating expenditure are substantially reduced.