The following GovTech article attempts to say yes. It may be an article you find somewhat interesting. Or, if burned by Enterprise Architecture in the past like many, you might find it trite. Or, you might be able to riff on it.
Current Status Of EA
- EA lacks support because people do not 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 is 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 brainstorming whiteboard session our staff came up with some of our own riffing on EA:
- How far can you go with the “building a home from a blueprint” analogy before it breaks down?
- For example, how detailed does a blueprint have to be before you can start building?
- Does the blueprint have to have the landscaping plan?
- Or, does it just have to have the core, structural details?
- When you are building a house according to blueprint, how are changes handled mid-construction?
- 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 is the EA analogy, if any?
- How agile and iterative can EA be?
- How quickly can you get from EA to implementation to demonstrating results?
- 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.
- Sometimes the organization realizes zero benefits because there is no transition to implementation phase.
- In any case, how exhaustive/comprehensive does the EA need to be before the organization can reasonably move out on some implementation?
- As we have 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.
- What are the boundaries, conditions for moving into incremental change?
- And what are the risks of moving in the wrong direction before completing an exhaustive EA?
- For example, if early analysis reveals that an organization is behaving like a products company but that it is mission, purpose and objectives mean that it’s really a services organization, can you start implementing change to address that?
- Is it still appropriate to architect just a “segment” at a time and rollout implementation then move onto the next segment?
- Can can organization views of EA go beyond aligning IT with the business/mission?
- For example, are some EA re-alignments purely process-based?
Our Response
Our comments are discussed in our approach to applying core architecture concepts, so the intent of this blog is not as greenfield as it may seem. They instead captured some of how this 20-year 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 back office systems to the front line of mission, scientific, and direct consumer service.