In short, yes! And it was not a humane end. It lived on way too long. As we noted in our 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 were 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 based. 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 efiling). As normally is the case when shifting positions of an asset to the executive level, this also means the investment models change and shift as it is now a critical part of executing transactions and interactions direct with the public, yet our policies are now 20-50 years old.
How Enterprise System and Conceptual Solution Architecture Approaches changed in 10 years
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 MBT and FSAM, Step 4 “Analyze the IT and Develop the Target Conceptual Solution Architecture” took 70 days. Now in CPM its a very high-level set of boxes for executives with risks done in less than a couple weeks with a series of transition plan notes to do it closer to implementation and investment budgetting time.
In MBT and FSAM, Step 4 was nearly identical. Here, its gone.
My 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 gets delayed or re-scoped, what if that enterprise workflow component is done differently, what happens to your architecture?
- service principles are becoming more best practices and standards like building guidelines which are less project specific, and more the project needs to choose at the right time what is required to apply.
The con could be to this the investment learns to late after budget season the true CAPEX (capital costs) and projects get further delayed. But, that is not all bad, as many time, the original CAPEX outlay is wrong anyhow, 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?
Dont we wish that could be true. That the tech developed in one group would integrate naturally with another. The data would perfectly interface. The security worked seamlessly. The protocols were hidden. Redunandancies and sunsets were robotically self-realized. OK, the last was too much tongue in cheek. But, no, systems must interface and be interoperable, accessible, and all the other architecture “ility” words.
So EA policy was constructed made for internal systems and local data centers. Now we are in utility hardware running software for the untrained user or trained user with very little time alotted. This is just a natural program as noted in IT Footprint Progression in the Federal Government… and the role of Architecture
All that being said, losing architecture is a reality in the planning. Disruptions are moving too fast. The best way we have found is making sure the agile development efforts are build on solids plans (per the above) and make sure the architecture principles, component selection is guided by an excellent architecture runway – either via governance or an enterprise agile framework.
We have more adopted a three-pronged approach
- 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