Random Enterprise Architecture Talk

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

Measurement in any type of program or project is essential. It is how we quantify both success and value. This is evidenced by the utilization of the SMART acronym in goal setting scenarios. SMART stands for specific, measurable, achievable, relevant, and time-related.  Fig. 1- Smart Goals http://www.evidenceinmotion.com/blog/2016/07/14/smart-patient-centered-value-based-goals/  In Enterprise Architecture measurement (the M in SMART) allows proper gauging of not only the program, but how it aligns with and supports the mission, vision and/or goals of the organization.  A great way to determine how well your EA program is doing is to establish high performance metrics. This can be done by assessing how your EA program supports your business strategy. When I say business strategy I am not referring to things associated with monetary reward programs or anything like that. When you filter out the fluff you are left with a true business strategy that drives the company. Michae

What in the world is EA governance you may ask. The term governance as explained by The Business Dictionary means “establishment of policies, and continuous monitoring of their proper implementation, by the members of the governing body of an organization”. Well this is also true in the world of enterprise architecture. Governance is a key component to the EA process. Governance is not limited to policies and observation, it is also inclusive of activities that the organization performs so that efforts are supported by measures of culpability. Think of EA as a great big trip. You have your Enterprise Roadmap for how to get from point A to B. Typically you don’t take trips without travel insurance, so why go in your EA journey without it? Governance as the protection plan for your EA journey. Those policies and monitoring provide checks and balances throughout the process. With EA being such an intricate program, there are inherent pitfalls that come with implementation. Ta

Why is performing a gap analysis so important? There are numerous reasons why a gap analysis is needed prior to EA program roll out. Ask yourself why you need to implement an EA program, what improvements need to be made and how you will complete those improvements. Well there are tools that will help to answer those questions and one of them is a gap analysis. What better way to answer those questions than to simply look at what you have (actual performance) and where you want to be in your optimized future state? Fig. 1- http://www.buzzanalysis.com/2016/07/31/ gap-analysis-what-and-how-all-you-need-to-know/ A huge step in introducing an EA program into any organization is a gap analysis. Where are the deficiencies that need to be addressed within the EA program/plan? Performing the gap analysis is something that will assist with alignment of systems for both function and utilization. When performing analysis you want to get something from the work that you put in. In this in

Current-state documentation is broken into three parts- conceptual application architecture, physical network diagram and business anchor model. These three parts are equally as important. In essence, they are like sides of a triangle and they balance each other out. Fig. 1 https://www.123rf.com/stock-photo/road_chaos.html In the current-state conceptual application architecture you will find depictions of the legacy systems in use and how they are used across departments and/or organizations. This illustration is a wonderful way to see where there is overlap and identify areas for integration. These problem areas now become opportunities for improvement and the basis for which the development of the EA plan goes forward from. In the current-state physical network diagram you get a view of the duplicative processes from another level. The physical network diagram shows clouds, firewalls, servers, VPN's and applications. The overlap identified here points out where you may

The implementation level of the future state architecture in EA is the next step in the sequence. At this point the organization has worked through conceptual process and logical process. It is time to progress to how to go about instituting the processes needed to build an ongoing EA program. In this level the organization will concentrate on the details. Things will be reined in- in stark contrast to the conceptual level. As illustrated in Figure 1, you will note that the higher the level the bigger the picture. As you drill down to the lower levels, the picture becomes more focused. The business process and how they will be impacted are clearly seen in the implementation level. Process maps, worksheets and technical network diagrams are artifacts that are created at this level. Within the artifacts there are certain relational dimensions that will be outlined to provide a good illustration of the end goal. You will find patterns, domains, services, components and products. These d