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. jqg5583June 18, 2017 at 7:24 PM

    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

Image
Enterprise Architecture IT strategy is yet another area of the EA program that requires documentation. Document development is instrumental to the success of an EA program because it gives the structure and rules that are needed for the organization to follow. When developing the IT strategy document an organization must form the plan of action needed to reinforce and sustain the mission, strategy and objectives of the organization. Fig. 1- Support Image (http://www.okclipart.com/Support-Group-Clip-Art30jdhthnii/) The document is specific to the contributory efforts of the IT department and be relatively brief. To help with illustrating what will be done, there are change requirement matrix that can be developed. One axis will show IT strategies and business change requirements. The other axis will show enterprise business strategies. How the items listed on both axis relate to each other is denoted by a marking in the corresponding intersecting box. With the aid of this matrix
Read more

Future State Architecture: Logical Level

Image
There are levels to future state architecture. The logical level incorporates communication tools. The logical level is evident in more than just a specific area; it is seen over various business functions. The logical level supports strategy and therefore includes information flows to executive leadership, information architect and EA teams.  In the logical level of future state architecture the logical information flow the customer is at the center of the diagram. This is important to note because with the customer at the center, you ensure that the along with the information that needs to flow out from the customers the appropriate information comes to the customer as well. Being involved in the  EA process embeds the customer in the program and gives them the appropriate amount accountability.  Risk management and  satisfaction are managed through information flow. Proper updates go across banking, underwriting, credit reporting agency, fraud management, information security, m
Read more