Monday, May 23, 2016

EA872 - Weekly Blog Entry 2

This week, the lessons revolve around launching the initiative of the EA structure.  In the text, chapter 4 deals with the various EA stages, and how to develop your infrastructure from one phase to the next.

Ross lists the four stages of architecture maturity as business silos architecture, standardized technology architecture, optimized core architecture, and business modularity architecture (Ross 71).  At a glance, the business silos stage consists of companies focusing their IT resources on local problems or opportunities (Ross 72).  A company would, naturally, align their IT resources to match the company's best interests.  However, at this stage the infrastructure only supports local issues.  Stage 2, or standardized technology, typically deals with companies shifting these resources from local to global applications.  By mandating a process of some sort, there is a minor shift in philosophy from reactive to proactive, whereby resources focus on global problems and solutions.  The optimized core focuses on moving from problem solving to an "enterprise view" (Ross 76).  This pertains more to EA upkeep, where staff spend time managing data, deleting redundancies, etc.  The end goal is to achieve the goals of the company by making use of reusable data.  Finally, business modularity refines the optimized core through repeatable modules.  This improves strategic agility, as process that were developed in the third stage are further refined (Ross 78).

Chapter 5 deals with typical outcomes of companies moving up from stage 1 through stage 4.  At a high level, IT is more responsive, less averse to risk, better satisfies management, and enhances business outcomes (Ross 96-100).  All these outcomes boil down to improved perceived value from company stakeholders, which seemed to be a big talking point during last week's lesson.  I've certainly witnessed firsthand that the more advanced an IT infrastructure is, the more it is able to accomplish and satisfy senior management.  This could mean bigger budgets and less tension between IT and the rest of the company.

Another interesting topic this week was Garter's paper on psychology and its role within EA.  He agrees that since EA is largely about designing change, people must see value in the change as well as the value exceeding the costs of the change. (Garter 4-5).

Thursday, May 12, 2016

EA872 - Weekly Blog Entry 1

This week, the readings focused largely on reviewing concepts from EA871, and identifying where your organization currently fits in the EA-building model.  The text states some common problems among polled organizations with regard to EA infrastructure; answers such as "different parts of our company give different answers to the same customer questions," and "our business lacks agility..." all signify poor foundational architecture (Ross 5).

So what?

Well, the bottom line is that companies with defined architectures perform better (Ross 2-3).  IT costs become lower, processes become more efficient, and the company moves from a reactive to a proactive environment.  Once your EA goals are in alignment with the goals of the parent company, this shift starts to occur.  This all must include the enterprise context, which can be achieved by collaborating with business and IT leaders, identifying trends and business strategies of the parent company, developing anchor models, and evolving the enterprise context over time. (Burton, 2-3).

Personally, the companies I've worked at weren't big on process - this implies a poorly developed architecture (or, in some areas a complete lack thereof).  This isn't just indicative of IT, but can be said of the company on a much larger-scale basis.  Asset integration and upkeep was messy - project managers developed their own ways of accomplishing their goals.  This was an issue in a highly regulated industry (oil & natural gas), where legislation dictates that the company must have a set of guideline which project follow.  The framework for enterprise architecture is there, but I don't see it implemented very often.

Compare this with some of the examples of the textbook, such as UPS, and I can easily see the merit in an organized, developed EA.  UPS has processes for nearly everything - they even tell their drivers which foot to put in the vehicle first (Ross 14).  Their process-oriented structure has allowed for the penultimate shift to a proactive company, whereby they can start developing tools to improve customer satisfaction (package tracking, etc.) to gain an upper hand on the competition.  It's really impressive how much EA can truly benefit an organization with total buy-in from senior management.