Future-State Architecture: Conceptual Level


Building an EA program is not simply evaluating where your organization is and identifying how to put Band-Aids on your current state. A very large part of implementing an EA program is conception- perceiving what will be. An EA Architect must outline the future-state to create the roadmap that will be followed to get there. There are numerous items for consideration in the conceptual phase including principles, process patterns, process typologies, information patterns, application architecture, and data stewardship requirements.

 

In organizations that do not take the time to envision their future state and consider the elements within the conceptual phase there are typically very poorly implemented EA programs. At times organizations implement programs in haste out of necessity and this leads to inability to implement properly. My organization often implements in haste and runs into these types of issues and the product is not well known, well received or utilized well. The best way to ensure that your EA program has a chance of success is to follow the steps below:

 

  • Involve a core architecture team that includes all of the necessary people (architecture domain teams, implementation teams, governance bodies)
  • Assess process flows
  • Determine how business processes relate to business functions
  • Incorporate project artifacts that depict:
    • How information inside and outside the organization is used to aid pursuit of the organizations strategy
    • Executive-level view of integrated applications and the impact on services/products
  • Establish policies that support the EA program and provide requirements

 

Having the right people in the conversations at the beginning of the EA journey will help to best determine what the focus of the EA program needs to be. And incorporating the right elements will get you the rest of the way.

Comments

  1. Over the past few weeks, I have had the opportunity to observe a few organizations where there was a lack of incorporating project artifacts that depict how the information inside and outside the organization is used. An organization that I had the pleasure to recently observe, had good governance and systems in place to an extent but failed in incorporating key stakeholders in the technical architecture and infrastructure development. Secondly, there were no working groups created as the organization created methodologies to help quickly translate business needs into application and infrastructure requirements. There was just one person working and driving the desired viewpoints and outcomes. This was caused due to the fact there was little to no planning and organizational leadership failed to take the time to envision their current state to move into a future state of readiness, built the plan in flight to meet needs as they arose. Due to a lack of poor project artifacts and working groups created devastating effects throughout the organization, negatively impacting desired goals and outcomes. "While there are certainly some hard-line architects who would be quick to point to all of the empty sections of the framework you’re neglecting, the bottom line is that EA programs have to be smart about scoping their efforts to ensure value is delivered and to avoid being swept up in a sea that you tried to boil. Resources aren’t unlimited in the real-world and EA programs are seeing the increased importance of thinking big, starting small, and scaling fast" (Joe Costello, 2017).

    References

    Joe Costello. (2017, February 6). WHAT’S WRONG WITH MY ENTERPRISE ARCHITECTURE? Retrieved June 18, 2017, from http://dominionconsulting.com/enterprise-architecture/

    vr,
    John Griffis
    Student, PSU

    ReplyDelete

Post a Comment

Popular posts from this blog

IT Strategy

Future State Architecture: Logical Level