Transforming Government I.T. With Architecture

 

Achieving Agility & Modularity

 

Call for action from Government

Transforming the way government leverages and acquires information technology is a key component of making government more open, efficient and responsive.  The U.S. Chief Information Officer has outlined specific actions that must be taken for the government to “fundamentally shift its mindset from building custom systems to adopting light technologies and shared solutions” and to get better value out of the spend on information technology.  Key aspects of this transformation are shared services, cloud computing, information sharing, agility and modularity combined with a restructuring of the I.T. management and acquisition processes.  The acquisition processes must be aligned with technology cycles and designed to foster modular, cost efficient and interoperable systems developed incrementally and iteratively.

The U.S. DoD has had multiple initiatives toward developing a new acquisition process for information capabilities”.  Specific principles include agile, incremental and iterative development, rationalized requirements and flexible/tailored processes.  The DoD must be able to plan, architect, acquire and integrate systems more quickly and less expensively.  Monolithic programs should be replaced by modular and open systems with a life-cycle that better matches mission requirements and technical innovation.

There is a clear need to transform the way the government acquires information technology yet many projects remain inefficient and unable to integrate across government.  This white paper from the Object Management Group’s Government Domain Task Force[1] shows how actionable architecture is a pre-requisite to these goals and suggests a roadmap for architecting agile and modular systems supporting shared services, cloud computing and effective acquisition processes.

 

Architecting for Modularity

Architecture at the scale of government systems specifies systems of systems and systems of major application modules. This can be differentiated from application architecture which focuses on how a particular module works internally.  Architecture in the large focuses on the space between the modules – how modules will work together to satisfy business and mission requirements.  Architecture in the large, or systems architecture, includes the services and information that is exchanged between modules and how the system of systems supports business needs, business services and business processes securely and reliably.  The resulting architectures are the specification for what each module must do as well as how it interacts with other modules and with users.  What systems architecture doesn’t do is over-specify how each module is implemented or its technology details.  These modules, with well-defined service and information boundaries, are then able to be acquired, developed and deployed independently – perhaps leveraging the cloud.  Modules may be internal or external to the enterprise which provides for shared services, shared information and collaborative processes among government agencies, citizens, vendors and mission partners.

Without understanding the systems architecture – what the modules are and how they work together, there is virtually no chance that usable and interoperable applications will emerge that satisfy business and systems requirements.  Without such a modular architecture, cloud computing can’t work except for isolated, non-federated applications.   Cloud computing is based on the capability for independent modules to interact over the internet to satisfy enterprise needs.

The architecture is the design supporting the I.T. plan to be acquired, developed, tested and deployed.  As there are few green field systems today, most systems architectures combine parts and services of what exists with new and revised capabilities.  The systems architecture encompasses the plan for how these new and existing capabilities will work together to support evolving business and mission needs.

Agile Architecture & Incremental Development

A key tenant of transforming I.T. is that the development processes must be agile, supporting an iterative and incremental life-cycle.  The life-cycle of development must be supported by the life-cycle of acquisition.  This is a radical change for government I.T.!  There is a substantial challenge in keeping all the “moving parts” coordinated in an environment where change is expected and planned for.   Agile development requires an engaged customer who may be altering requirements as they better understand the solution and the ability of providers to deliver fast and often in response to this dynamic environment.  The plan that keeps this in sync is the architecture – a living, actionable plan that reflects what exists and what is to become, but light-weight so that producing the architecture enhances the agile process without unnecessary burden. Because portions of the system can be automated from the architecture, adapting to change is more rapid and less expensive.

Architecture has too often and mistakenly been coupled with heavyweight waterfall processes that are the antithesis of agile. Actionable architectures that support agility must be a living reflection of the system as it evolves. Agile actionable architectures support the design, acquisition, development and testing processes.  The architecture of the space between the modules makes sure that as the modules evolve they will work together in support of the business and mission.

Architecture in support of Acquisition

acquisition of I.T. systems has traditionally been monolithic and heavyweight – the design, implementation and testing of entire solutions delegated to a systems integrator.  When a monolithic system with static requirements is contracted, that is exactly what is produced – a monolith.  Interoperability, modularity and evolving user requirements are not part of the process.  A systems architecture where the services, exchanged information and responsibility of modules are understood in the context of the business and mission becomes an actionable specification of each module – one that can be built to order and tested.  As requirements change they are reflected in the architecture so that adjustments in all the modules can be made – maintaining the integrity of the entire system and traceability to requirements.  Modules with will defined boundaries can be re-built and re-deployed to new technologies so the system never becomes hostage to a particular technology or vendor.

Actionable architecture provides information that can directly support the acquisition process with specifications that are sufficiently detailed, but not overly constraining.  In an agile and modular environment it is imperative that the government takes ownership of its architecture so that COTS systems, contractors and developers can effectively deliver components into the evolving solution.  Actionable architectures become part of the agile acquisition processes.

Standards based Actionable Architecture

The Object Management Group[2] (OMG) is the leading world-wide consensus standards organization for modeling.  The OMG brings together government, industry, academia and vendors to develop standards that vendors commit to implement.  Modeling standards of the OMG include the Unified Modeling Language (UML), Business Process Modeling Notation (BPMN), Systems Engineering Modeling Language (SysML), Unified Archit4ecture Framework (UAF), Ontologies (ODM), and others.  OMG modeling languages are defined under the umbrella of the vision of “Model Driven Architecture[3]” (MDA).  MDA provides for architectures in these modeling languages to be actionable, to directly support acquisition, development, testing and integration by producing program, service and development artifacts directly from the architecture – MDA architectures are not “paper tigers” but an integral part of the acquisition and systems life-cycle.  MDA focuses on separating concerns. Making modeling the business architecture supportive of but independent of any of a number of technologies that can be used to implement it.

The OMG also provides the process for government and industry to come together outside of the acquisition process to define standards that directly support government.  Successful standards driven by government include the Records Management Service[4] (RMS), done in cooperation with National Archives (NARA) and the Model for Performance Driven Government[5] (MPG), done in cooperation with the Office of Management and Budget (OMB) and UPDM, the UML representation of DoDAF done in cooperation with the U.S. Office of the Secretary of Defense.

OMG also provides certification for architecture standards that could help the technology fellows program as well as help HR professions identify candidates with these key competencies.

 

Steps to achieving Agility and Modularity

Achieving agility and modularity with actionable architectures is not theory or research, it is current industry best practice supported by existing tools and services.  Specific steps that can be taken now include:

Actions Benefits Support of government initiatives
Integrate actionable architecture requirements into acquisition vehicles Acquisitions will support a modular architecture with well-defined and testable components.

Once acquired these modules can be tested for compliance and expected to interface with other enterprise systems based on well defined interfaces.

  • Develop a strategy for shared services
  • Identify IT acquisition best practices and adopt government-wide
  • Issue contracting guidance and templates to support modular development
  • Requirements will be documented, prioritized, and traceable
  • Emphasis will be placed on architecture compliance, standardized information definitions, and rationalized performance requirements.
  • Business Architecture will be conducted to ensure that IT solutions are undertaken that support well documented and efficient operations.

 

Acquire smaller modules that are expected to evolve with requirements.

Practice agile architecture – architect in small steps as part of an agile development process

Large “big bang” projects are risky and expensive.  Starting with an architecture for modules that can incrementally evolve to satisfy systems requirements is less risky and produces better results.

However, we have to get used to the idea that we will not know every requirement of a system prior to construction starting.  A system of systems architecture provides good balance between chaos and analysis paralysis.

  • Identify IT acquisition best practices and adopt government-wide
  • Business case analysis will precede and inform the proposed approach.
  • Emphasis will be placed on architecture compliance, standardized information definitions, and rationalized performance requirements.
  • A modular open system approach will be applied to foster open architecture, enable the widest selection of vendor options for ease of upgrades, and encourage competition throughout the life cycle.
Establish an architectural center of excellence with supporting architecture repository and collaboration platform.

Have the COE prepare strategies and architectures to support shared services and could computing.

Developing an agile architected approach to cloud based modular systems takes expertise and resources that may not be currently available.  Establishing a center of excellence provides a resource, leadership for the agile development community and a way to coordinate diverse efforts.
  • Require Integrated Program Teams
  • Launch a best practices collaboration platform
  • Identify IT acquisition best practices and adopt government-wide
  • Develop a strategy for shared services
  • Shift to a “Cloud First” policy

 

Align the business architecture with the systems architecture as part of the enterprise architecture Systems, no matter how technically successful, that do not align with business needs and goals are poor investments.  A business architecture that lays out the business services, processes and information needed to support the enterprise provides context, priorities and requirements for systems development efforts.  Both business and systems architecture should be agile, evolving with the needs of the business and technical realities.
  • Business architecture will be conducted to ensure that IT solutions are undertaken that support well documented and efficient operations.
  • Reform and strengthen Investment Review Boards
  • Emphasis will be placed on architecture compliance, standardized information definitions, and rationalized performance requirements.
Pilot a model driven architecture approach Gain confidence and experience with an architected approach using a pilot program.  Investments in pilot programs reduce risks for larger follow-on programs.  Expect pilot programs to be a learning experience.
  • Expand set of pilot projects to fine-tune the new processes and initiate pilot portfolio
Use agile MDA as part of the development life-cycle from design through test

 

Model driven architecture is a full life-cycle approach that can reduce time and costs from system inception through ongoing maintenance.  Tune the SDLC to support an agile architecture approach.
  • As applicable, modern commercial IT processes will be adopted, such as model-driven development, user-centered design, feature-driven developments, and other proven IT practices to improve acquisition outcomes.
  • Test and evaluation will be structured to support iterative and incremental delivery, making extensive use of prototyping and automated testing, and will be integrated with certification and accreditation activities.
Participate in the OMG to help drive standards supporting government Participation in standards organizations provide unique opportunities for learning as well as a way to participate with other government agencies and industry outside of the acquisition process.  Government can and should participate in the development of standards that are relevant.
  • Outreach to industry will be conducted to gain insight into commercially driven industry trends.
Put a cloud based web accessible architecture repository in place that is accessible cross program and cross agency Collaboration, cloud services and shared services require that information is available between the providers and consumers of services and information.  Publishing standards based architectures on the web enables customers and the supply chain to better understand what services, products and information each organization uses and requires.

Publishing architectures also serves to implement the President’s open government initiative.

 

  • Today’s traditional paper-based documentation will be consolidated into fewer planning, execution, and reporting documents and replaced to the maximum extent possible with on-line tools that increase transparency and collaboration.
  • Information assets needed to support the requirements (capability) will be characterized in the context of the business processes or mission to be supported.
  • Develop a strategy for shared services
  • Shift to a “Cloud First” policy

 

Copyright © 2017, Data Access Technologies, Inc as Model Driven Solutions.

 

[1] OMG Government Task Force: http://gov.omg.org/

[2] OMG: http://www.omg.org

[3] MDA: http://www.omg.org/mda/

[4] RMS:  http://gov.omg.org/gov-rfp-rms2.htm

[5] MPG: http://gov.omg.org/gov-ftf-mpg.htm

Leave a Reply