Can Enterprise Architecture be demystified

Can Enterprise Architecture be demystified?

The following GovTech article attempts to say yes. It may be an article you find somewhat interesting. Or, if you have been burned by Enterprise Architecture in the past like many, you might find it trite. Or, you might be able to riff on it. Here’s what are some 101 points one can get out of it:

  • EA lacks support because people don’t understand what it is
  • Using the “building a home from a blueprint” analogy can help (to a degree)
  • Explaining EA terminology (framework, model, blueprint) can help
  • EA is about the business (or mission), not IT; It’s about getting IT to align with the business (or mission)
  • For EA, the federal government is leading (ahead of states and other jurisdictions)

That said, in a brainstorm, virtual whiteboard session, and here are some of our own riffing:

  1. How far can you go with the “building a home from a blueprint” analogy before it breaks down?
    1. For example, how detailed does a blueprint have to be before you can start building?
    2. Does the blueprint have to have the landscaping plan?
    3. Or, does it just have to have the core, structural details?
  2. When you’re building a house according to blueprint, how are changes handled mid-construction?
    1. If the building owner walks through the roughly-framed house and notices the natural lighting patterns and wants to add a set of windows and move a closet, the blueprint enables you to manage the change, understand the impacts, account for the impacts. What’s the EA analogy, if any?
  3. How agile and iterative can EA be?
    1. How quickly can you get from EA to implementation to demonstrating results?
    2. This gets to another obstacle to organizations embracing EA: it takes too long to architect the entire enterprise before the enterprise begins to experience the benefits.
    3. Sometimes the organization realizes zero benefits because there’s no transition to implementation phase.
    4. In any case, how exhaustive/comprehensive does the EA need to be before the organization can reasonably move out on some implementation?
  4. As we’ve seen, starting some transformation in parallel to completing the full EA blueprint and roadmap can begin to improve the organization and move it in the right direction.
    1. What are the boundaries, conditions for moving into incremental change?
    2. And what are the risks of moving in the wrong direction before completing an exhaustive EA?
    3. For example, if early analysis reveals that an organization is behaving like a products company but that it’s mission, purpose and objectives mean that it’s really a services organization, can you start implementing change to address that?
    4. Is it still appropriate to architect just a “segment” at a time and rollout implementation then move onto the next segment?
  5. Can can organization views of EA go beyond aligning IT with the business/mission?
    1. For example, are some EA re-alignments purely process-based?

Our comments of course were discussed in how our approach to core architecture concepts apply, so the intent of the blog was not as greenfield as it may seem, but capture some of how the now near 20 year somewhat mainstream practice may need to evolve further to adjust to agility that came about post-internet, utility commodity models (aka cloud), and moving data from ERP backoffice systems to the frontline of mission, scientific, and direct consumer service.