In short, yes. And it was not a humane end, because it honestly lived on for way too long. We noted such in our previous blog: What do current disruptive technologies mean to the roles of the Federal CIO office.
Traditionally, the operating model and funding approach for IT has been based on the Brooks Act of 1965 and only added minor portfolio integration concepts based on the Clinger-Cohen Act of 1996. These acts focused on internal IT cost-based centers, management information systems, mission control systems, and enterprise resource planning systems. These systems were all either internal mission or data processing systems used to run business. Since 1996, a lot has happened in the IT cost-based center concept. It has moved from cost center to profit center in the private sector, and in the government space to service or profit center as well (i.e. profit for IRS in e-filing). And when shifting positions of an asset to the executive level, the investment models change as the asset is now a critical part of executing transactions. And interactions direct with the public, yet our policies are now 20-50 years old.”
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