To expand on that blog, we would like to revisit those two acts and what they meant for this subject. For example, the Clinger-Cohen Act was meant to reform acquisition laws and information technology management of the Federal Government. Meanwhile, the Brooks Act required the government to select engineering and architecture firms based upon competency, experience and qualifications, rather than price.

How Enterprise System And Conceptual Solution Architecture Approaches Changed In 10 Years

As we previously noted in FSAM Replacement – Collaborative Planning Methodology (CPM), the new CPM…

is still the same “original concepts of governance gates between major decision points/steps, step at-a-glance view, work product based methods”.

…

“but you can see the appropriate gravitational move less from system architecting to portfolio designing to roadmapping”.

For instance, in the Methodology for Business Transformation (MBT) and Federal Segment Architecture Methodology (FSAM), Step 4 is meant to “Analyze the IT and Develop the Target Conceptual Solution Architecture”, which took 70 days. But in CPM, executives see risks done in less than a couple weeks with a series of transition plan notes to do it closer to implementation and investment budgeting time.

In MBT and FSAM, Step 4 was nearly identical. It is nonexistent, here.  Our assumption is three-fold:

• By the time the team goes to invest, doing conceptual target solution architecture has already aged 6-18 months
• Target solution architecture depends highly on the progression of other enterprise services. What if the cloud contract experiences delays or re-scoping? Also, what if that enterprise workflow component finishes differently? What happens to your architecture?
• We see service principle become more best practices and standards like building guidelines which are less project specific. Also, more the project needs choosing its application requirements at the correct time.

The con in this, could be the investor learns too late after budget season of the true CAPEX (capital costs). Consequently, it further delays projects. But, that is not all bad, as many times, the original CAPEX outlay is wrong anyhow. This is true, even with a good conceptual solution architecture due to the notes above.

Does This Mean Architecture Should Not Be Done At The Enterprise Any More?

We really do wish that could be true. That the tech developed in one group would integrate naturally with another. The data would perfectly interface. The security has worked seamlessly. It hid protocols. Redundancies and sunsets self-realized themselves robotically. But, no, systems must interface and be interoperable, accessible, and all the architecture “ility” words.

EA policy constructed itself for internal systems and local data centers. Now we are in an era of utility hardware running software for the untrained or trained user with very little time allotted. This is a natural program as noted in our blog: IT Footprint Progression in the Federal Government… and the role of Architecture

That being said, losing architecture is a reality in planning. Disruptions are moving too fast. Ensuring agile development efforts were built on solid plans (per the above) was the best method found. Also, architecture principles, and component selection require an excellent architecture runway as a guide. Do this either via governance or an enterprise agile framework.

We have more adopted a three-pronged approach to address this change:

• Strategically building collaborative relationships with our clients using Smart Lean Government concepts of building communities, integrating life events across organization types, and working towards a standing Service Integration Model
• Tactically, doing the Step 4 work products when needed
• Timing the tactical work products by implementing Agile with Architecture in concepts driven by Scaled Agile Framework