• 🏛️ Why Government Needs a Living Enterprise Architecture, not a Static Blueprint

    The Trap

    Having spent many years designing, building, implementing, and sustaining enterprise architecture, I often see agencies treat it as a one-time deliverable.

    This static blueprint fails to reflect the dynamic nature that all agencies experience.  This creates rigid structure that does not allow for adaptable response to mission changes, new technology, or active threats.  This is the type of limitation that makes a living architecture essential for mission success.

    Enterprise Architecture, traditionally, is a strategic discipline that maps out how mission, operations, and governance align to provide value to the American public.  As a blueprint, it supports policy, planning, service delivery, and compliance.  However, this traditional role lacks agility which leaves Enterprise Architecture disconnected from real-world operational needs.

    The problem

    As anyone who has worked in or with the government is aware, bureaucracy and red tape are two things we know we can count on.  The existence of these extensive approval and authorization processes will inherently make innovative solutions obsolete by the time they can be implemented.  This has become the single greatest threat to the static model of an Enterprise Architecture blueprint as it ignores operational constraints, evolving policy, directives from the executive branch, and real-time data meant to convert insights into quick adjustments to operations.  Enterprise Architecture then becomes a check on a box as opposed to an enabler of strategic objectives.

    What a Living Architecture Looks Like

    Where a living architecture demonstrates its value is in continuously updated models that reflect changes in systems, policies, user needs, and threat response.  Integrating Enterprise Architecture into the Agile delivery model allows it to evolve alongside value streams and their iterative development.

    This allows the architecture to change in real time, following the configuration management plan to implement new governance, risk assessment and mitigation, and compliance which follow the same mission-centric mapping that the agile teams follow.

    Where we’ve become accustomed to the idea of DevSecOps, those same principles can be applied to Enterprise Architecture by delivering policy-as-code, automation, and observability tools.

    This constant review of the architecture keeps everything up to date and compliant with whatever framework you are following as new guidance is released from your IT Security Office, your department, or any of the IC agencies tasked with providing us with secure requirements.

    The Benefits

    Now that we’ve avoided the trap set by rigid architecture, identified why that trap exists and the problems it poses, and have successfully identified what a living architecture looks like, I’d be remiss to not cover why I think it’s beneficial in the first place.

    Agility is a word that has become ubiquitous in our field of work.  However, its meaning varies as much as the number of people who think they know what it means.  That said, the formal definition is, “an organization’s capacity to rapidly adapt and respond to changing technical requirements, emerging technologies, and evolving business needs”. 

    How this shows up in Enterprise Architecture is in rapid response to crisis or threat which often are accompanied by a shift in guidance.  Traceability, managed through artifact repositories, creates transparent pathways detailing solutions from their initial objective through solutioning and implementation.  To be Agile in Enterprise Architecture accelerates modernization, reduces unwanted redundancy, and streamlines procurement processes.  Lastly, collaboration across and inter agency is improved because a living architecture considers consolidating assets and services to best support the Enterprise.

    Adoption, or the lack thereof

    For most agencies, once an Enterprise Architecture is delivered, there is no indication that they will return to it for major changes anytime soon.  To meet any security assessment, you’re simply asked to review it once per year.  For shifts in guidance or posture, capabilities are tacked on and attempt to inherit any defined governance that preceded it.  These are all barriers to adopting a living architecture which are ingrained into the culture.

    Lack of tooling?  You could technically drive a nail into a board with a spoon, but do you really want to?  A hammer would be much easier, faster, and repeatable.  Asking anyone to perform a task without the tools to do it well will result in a lack of adoption, poor performance from those who attempt, and downright non-compliance.

    But the king of them all, the client just doesn’t want to do it.  This is often a sentiment for those who are unaware that a problem exists, unsure of what the solution means, and are unconvinced how this benefits them.  As Enterprise Architects, that’s where we come in.

    Our Role in Driving Change

    Now that we are here, as EA’s, we are well positioned to evaluate the scenario, identify where the problems exist, define the solutions, explain the benefits, ensure adoption, and drive the change.

    At the outset, we are advocates for well-defined requirements.  Where we can greatly assist is in helping convert business and mission objectives into actionable project plans.  This will ensure that when Enterprise Architecture is being developed it aligns with the greater service delivery.

    Communication becomes a significant portion of successfully driving adoption.  Given this will likely be a departure from business as usual, clearly explaining (no technical mumbo jumbo) the process detailing all the wonderful benefits but also the level of effort and pitfalls if not done correctly, will help provide realistic expectations, timelines, and budgets – all of which are necessary to successfully drive this type of change.

    From Blueprint to Backbone

    Which brings us to our conclusion.  We must make a call to action.  As change agents in our field we must call for our agencies to treat Enterprise Architecture as a system that requires continuous reassessment.  It is not just a *.PDF with diagrams that gets delivered once and never touched again.  EA is the strategic backbone that must evolve with the agency’s mission.

    As a living entity, its nature is to grow and change over time.  Let’s make sure that happens.

    “Architecting the future of technology and business through transforming challenges into opportunities.” – Malik Griffin

  • Maiden Voyage

    pour ce premier post je n’ai rien Ă  dire