Styles of Architecting

A Smarter Approach to Architecting

A successful architecture effort starts with a meaningful dialogue between the customer of the architecture output and the architect. Architecting approaches tend to fall into a range of categories. If the architect and the customer are able to understand the category of architecting required for a particular problem then this gives strong guidance on how the architecture should be developed and governed. These categories of architecting are called Architecting Styles and provide a place to start an architecture effort; they provide guidance and help to set expectations with the sponsors and stakeholders.

The four styles of architectingFigure 1 - The four styles of architecting

The Styles are a valuable tool in helping to overcome some of the issues that affect architecting which can result in architecture project failure. This can be caused by misplaced expectations as to the outcome and effort required (including maintenance) for the architecture, and consequently they are of no immediate value to decision makers. Key to this is that many approaches and Frameworks exist; however, there is not a good understanding as to what each one will deliver and that one size will not fit all. Some architectures will have longevity and require strong and sustained governance, others are only required to support shorter term objectives, such as to investigate a decision, or support a change activity. The architectural approach should take these differing requirements into consideration.

To gain a shared understanding of both the problem area and the approach, the Styles consider the relationships between key elements. These are the architecture Principles.

The principles of successful architecture will define the problem and approach, and guide you to the correct style:

  • VALUE. The Purpose of the architecture will directly drive the shape and form of the Outputs And Outcomes;
  • SCOPE. The Area Of Concern will dictate what Reference Models or standards need to be considered and (re)used;
  • CONTROL. The Level of Change will identify the type of Governance that needs to be applied and by whom;
  • DELIVERY. There is a strong synergy between the Development Method and the Enablers. This relationship will be influenced by each of the other components in turn as reflects the constraints of the approach, eg use of a corporate tool or framework.

Use these Principles to understand the problem and inform the approach.

The principles are shown below along with some of their attributes. These should be considered during dialog between the architect and sponsor to fully understand the context of the problem area and from this the approach that is best suited to achieve the desired benefit from the architecture effort.

The principles of architectureFigure 2 - The principles of architecture.

Once the sponsor and architect have considered the Principles and fully understood the context, the architecture approach should be developed using the characteristics of the four Architecting Styles as a guide.

The figure below summarises the characteristics that are detailed in more depth in the tables below.

The characteristics of the four architecture stylesFigure 3 - The characteristics of the four architecture styles

 

Example: Authoritative

A key foundation to realising the vision of information capabilities that serve as a "force multipler" is the establishment of Defence as a Platform (DaaP). DaaP is the means by which the delivery of information capabilities moves towards a shared-platform model in order to provide a more cost-efficient and unified service.

Niteworks were tasked with developing the strategic reference architecture for DaaP, drawing on pan-industry input to define a mature view of the capabilities required to realise the vision. The Niteworks partnership between MOD and over 160 industry organisations was the ideal vehicle to deliver this project.

Niteworks developed the strategic reference architecture for DaaP and documented the results in the ‘DaaP jigsaw’ which provides a framework for the guiding principles, reference models, processes required for the continued iterative development, delivery and maintenance of DaaP.

 

Example: Coordinative

The ISTAR & IO Enterprise has historically provided specific, bespoke, domain and platform centric solutions to deliver Military Capability. The Direct, Process & Disseminate Capability Investigation (DPD CI) sought to identify gaps, overlaps, shortfalls, redundancy and project inter-dependencies in the DPD portfolio in order to support the development of a coherent, affordable and viable DPD Capability Management Plan.

The project developed a Capability model and Service Taxonomy based upon the capability requirements specified in Doctrine. The projects within the DPD portfolio were profiled against the Service Taxonomy, which enabled the identification of functional overlaps and interdependencies in the planned provision of the capability.

The Enterprise Model provided the ability to clearly articulate the Capability Requirements to the Delivery Organisation and expressed the contribution of projects in terms of Capability. It gave a Common and improved understanding of the enterprise, meaning that it improved the ability to make decisions holistically across the enterprise. Capability Gaps and overlaps were easily identified and the impact articulated, additionally the use of differentiators to characterise projects allowed the prioritisation of further intervention. This architectural approach resulted in the identification of significant savings in the delivery of ISTAR & IO capability.

 

Example: Supportive

Niteworks provided support to the Future Maritime Fires programme through the generation of Requirements, updating previous Operational Analysis (OA) and the development of Capability and Cost Models. These outputs were exploited to improve and expedite decision making, reduce risk and support the Approvals process within MOD. Niteworks specifically examined the potential Medium Calibre Gun (MCG) solutions for T26 Global Combat Ship (GCS), T45 and/or T23.

The Capability Model integrated the cost and performance models in Microsoft Excel with the capability definition architecture in the architecture modelling tool, MooD, to provide a holistic view of effectiveness, cost and risk for the Capability options. Priorities assigned in the URD were used by the Capability Model to weight the score of the MCG options against Requirements. Whole life costs were taken from the cost model, and operational effectiveness, in terms of the number of engagements satisfied by each weapon system, were drawn from the operational analysis.

The resulting Capability Model supported MOD to make and brief decisions on MCG solutions by capturing and presenting visual summaries of the relevant data in one place.

 

Example: Directive

Defence Operational Training Capability (Air) (DOTC(A)) will radically change the way that Defence conducts operational training across the Enterprise in the air domain. DOTC(A) will be a complex system of systems that requires careful planning and design so that it can establish the correct people, organisational structures, technology and business processes to succeed.

An Enterprise Architectural approach, underpinned by MOD Architecture Framework (MODAF)-based modelling has been used to support analysis of the user requirement and the subsequent development of the system design. The system design has been captured as a series of Enterprise Architecture views and descriptions from a variety of specific stakeholder perspectives and are collectively referred to as the DOTC(A) Enterprise Architecture Model (EAM).

The DOTC(A) EAM has been specifically configured to support the capture and definition of DCS&S system requirements in an Acquisition Systems Guidance (ASG) compliant format. A methodology has been successfully developed, tested and executed to provide the captured DCS&S system requirements in a suitable export format that can be directly exploited in the generation of a System Requirements Document (SRD). And in the future can be synchronised between the MOD’s preferred requirements management tool (IBM Rational DOORS) and the DOTC(A) DEAM development tool, (MooD Business Architect).

The DOTC(A) EAM has also been developed to incorporate other related Niteworks DOTC(A) outputs, including the Integrated Test, Evaluation and Acceptance (ITEA) Framework Guide, Test Case Scenario, Model Based Requirements Navigation and a Mission Analysis Model Directory.

The DOTC(A) Mission Analysis Modelling activity that has been conducted during previous stages of Niteworks DOTC(A) support had the primary purpose of informing and ensuring the DCS&S system requirements, as captured in the DOTC(A) EAM, are robust. DOTC(A) Mission Analysis Models (MAMs) have also been exploited for other purposes, which have provided additional benefits to MOD. By conducting mission analysis for the agreed DOTC(A) Force Elements, all interaction types and entities can be identified. Therefore, representing the ‘Training Requirement’ that effectively must be delivered by the future DOTC(A) synthetic training capability.

Author: John Kendall

John Kendall is the Chief Architect at the Niteworks partnership. John has been involved in Enterprise Architecture for over 10 years and has been Lead Enterprise Architect on a number of large programmes delivering capability or performing business transformation. John was also a member of the MODAF Partners team who originally developed the MOD Architecture Framework (MODAF).