EA872 - Weekly Blog Entry 12

This semester has taught us a lot, as we expanded our knowledge of EA and IT infrastructure, explored new tools with which to refine an existing infrastructure, and developed plans to continuously analyze existing EA in the hopes of improving resource usage and efficiency in line with organizational goals and missions.  Through constant communication, as well as the Bank XYZ prototype, we can now apply this knowledge to our organizations.

All-in-all, we now have the pieces to make the vision a reality.  We can define our vision for the future state EA.  We can document the current state and present it to others.  We can analyze the current state to understand where the gaps are.  We can develop a comprehensive plan for how to achieve the ideal future state architecture.  And most importantly, we can support the overall EA effort with constant and thorough communication.

EA872 - Weekly Blog Entry 11

IT strategy:  where do we start?  Given everything we learned this semester, how do we formulate the change to take advantage of all the benefits EA has to offer?  Sure, the deliverables and tools we've seen are great ways to organize the information regarding EA and explain it in layman's terms.  But without a solid plan, how do we know we're truly making the most of every resource?

Planning and oversight, according to the readings this week, are grouped into three key areas:  IT Strategic Plan, Enterprise Architecture, and Realizing the IT Strategy.

IT planning is typically in line with a company's strategic intent.  This allows the plan to be developed in line with the company's goals, an often recurring theme in EA.  An IT plan can include IT demand, as it will often change at various times throughout the year, and strategic planning, which allows a company to take a look at their current IT state to better understand what is needed to achieve the end goal.  By examining the different routes a company can take to achieve its goals, it can minimize resource utilization and risk.

Developing the EA will help connect IT to the business goals of a company, since there is typically a bond between business strategy and technology implementation.  Essentially, developing the EA is all about getting the most out of IT, as business alignment is optimized.

Realizing IT strategy is the final step, and perhaps the most difficult.  That is because realizing a strategy ultimately requires oversight to make sure personnel are in agreement regarding the ultimate end goal.  Unless proper communication is maintained, interdepartmental conflict can erupt and cause chaos.

Enterprise Architecture Improves IT Planning Synergies, Gartner.

EA872 - Weekly Blog Entry 10

Lesson 9 is all about how your organization's EA framework measures up and common pitfalls that pop up along the way towards EA improvement.  I thought the measurement matrix was an interesting tool for organizing these thoughts in a way that can help explain EA in layman's terms.

The second of this lesson's readings describes the measurement matrix in detail.  The process for development and implementation of an EA measurement program has the following steps (Weiss 2):

1. Planning — mapping metrics to strategies
2. Assessing the organization — comparing capabilities with goals
3. Designing and identifying effective measures
4. Building the measurement process
5. Implementing and measuring
6. Communicating appropriate results to appropriate stakeholders
7. Reviewing, changing and improving performance

Weiss goes on to state, "the metrics used should be statements that link to the assessment area and include some quantitative or qualitative representation of the final measure."  For example, number of products licensed versus established licenses leveraged would help us look at reuse of software and financial efficiency.  (Weiss 4).  Overall, I think organizing data this way makes it much easier to understand where your EA is currently at within the organization.

The main point of this tool, in my opinion, is to help evaluate the results and manage poor performance.  After all, that's how you get true measurement and that's how you embrace continuous improvement within EA.  At the end of the day, as processes are continually changing, your are alwys trying to hit a moving target.

EA872 - Weekly Blog Entry 9

This week, we ask ourselves about leadership:  what is the leadership agenda for creating and leveraging a foundation for execution?  (Ross 188).  The text goes back to Chapter 1, where we listed nine common symptoms of an ineffective foundation; from there, it describes key ways to rethink an organization to mitigate (or hopefully completely remove) these symptoms.

1. One Customer Question Elicits Different Answers.
2. New Regulations Require major Effort.
3. Business Agility is Difficult and Growth Initiatives Aren't Profitable
4. IT is Consistently a Bottleneck
5. Different Business Processes and Systems Complete the Same Activity
6. Information Necessary for Making Decisions is Not Available
7. Employees Move Data from one System to Another
8. Senior Management Dreads Discussing IT Agenda Items
9. Management Doesn't Know Whether it Gets Good Value from IT

Each lesson over the course of this semester will help improve a company's architecture - everything from analyzing the existing infrastructure to designing the new model, and growing it horizontally or vertically.  But at the end of the day, it is up to leadership to facilitate the change.  The top ten leadership principles to achieve this are as follows (Ross 206):

1. Commit to the Foundation
2. Initiate Change from the Top and Remove Barriers
3. Feed the Core - Experiment
4. Use Architecture as a Compass and Communication Tool
5. Don't Skip Stages
6. Implement the Foundation One Project at a Time
7. Don't Do it Alone - Outsource
8. Invest in Your People
9. Reward Enterprisewide Thinking
10. Empower Employees with the Foundation for Execution

EA872 - Weekly Blog Entry 8

Profit, profit, profit.  That's it, folks:  money.  It's what makes the world go 'round.  This week, we took EA one step further and learned how to use the foundation we've created for profitable growth.  After a quick lesson regarding the difference between organic and acquisition-driven growth, we can look at a few scenarios:

In a unification model, a maturing company continuously refines and matures its EA foundation.  Through this strong, broad foundation, more processes are streamlined and digitized, which translated to better customer service and repeat-ability of results.  (Ross 167).

A replication model has companies leverage business processes rather than data.  With a maturing company refining their processes, rapid growth can occur in emerging markets or new products.  By opening more streams of cash flow, the company becomes more profitable.  (Ross 169-170).

A coordination model is more complex in that it uses its foundation across multiple businesses, sometimes offering drastically different services or products.  By using a more generic approach, a company can focus on customer interaction, often aiming at identifying "the need behind the need."  For example, by knowing your customer's habits or patterns, you can identify what project they are working on or what product they may need in the near future.  Then, increased profitability comes from upselling or adding on extra items.  (Ross 172-174).

The diversification model is the oddball:  there is typically no integration or standardization cross business units.  Why?  Sometimes it makes more sense to give business units the autonomy to do things their way - if they know a specialized business better than a central authority, for example.  (Ross 176).

EA872 - Weekly Blog Entry 7

This week’s reading is about harnessing the mighty EA to guide outsourcing – that is, outsourcing of IT practices to other companies and industries.  The three types of outsourcing relationships include strategic partnerships, co-sourcing partnerships, and transaction relationships.  Each, according to Ross, has its own benefit-risk profile (Ross 144).

Strategic partnerships are when a vendor provides an integrated service.  This can include applications, infrastructure, personnel management, etc.  But the point is that it allows companies to focus on their core objectives while an outside vendor handles the day-to-day operations (Ross 147 - 148).  I would think start-up companies or those with limited resources would find this partnership more attractive, both because of limited cash flow, personnel, and a very real jump towards standardization.

A co-sourcing partnership, much the opposite of the strategic partnership, develops responsibilities for both parties involved.  It’s a more symbiotic approach to achieving success when both companies have skin in the game (Ross 153).  I’ve seen this before in the oil field on joint venture projects.  Because pipelining is so expensive ($2MM per mile in some areas), often times two or more companies will come together to split responsibilities and resources.  This is especially true when such infrastructure spans multiple states (as it most often does).  One company may supply more capital and personnel (project manager, welders, pipeliners), while another supplies right-of-way specialists to negotiate with local, state, and federal agencies, as well as private landowners.  Although not directly relateable to IT, the principle is the same.

Transaction relationships are more straightforward.  Through outsourcing specific functions, there is a definite corollary between transaction relationships and strategic partnerships.  The difference is that transaction relationships also outsourcing ownership of the processes.  Maybe this is why transaction relationships are deemed much more successful than strategic partnerships (Ross 157).  As processes are isolated from the other company, clientele are enabled with a bit more autonomy tan the other processes.  

EA872 - Weekly Blog Entry 6

Now that we've broken down the logic behind an EA framework, we can take a look at how we are going to implement it.  A lot of these tools will mirror their counterparts in the logical view.

A detailed process diagram is much like the logical process diagram.  It shows flows from one process to another, detailing a comprehensive, future-state EA through which the company will eventually reach its goals.  But it differs in that it doesn't stop short of process logic like the logic diagram.  Rather, it will break down each process into constituent parts.  One detail in the readings displays a company's process for "opening a new customer relationship."  A step by step definition follows to achieve this goals.  The beauty is that this goal can be anything the company is trying to achieve - which is what makes an EA so valuable when done correctly.  It will standardize any process so as to bring about a consistent customer experience.

Moving on, a technical network diagram will break down a company's technology.  Again showing how to accomplish the job, this nifty little tool focuses less on particular applications and shows a more general layout, including various levels of interaction between servers.

EA872 - Weekly Blog Entry 5

This week, we broke down a future state architecture into its components:  a logical process pattern, a logical information viewpoint, a logical services architecture, and a shared infrastructure services diagram to name a few.

A logical process pattern can be compared to a flowchart, with various processes listed and linked to others, with the end goal of establishing how to manage these processes individually.  This could apply to acquiring new customers, maintaining old ones, managing supply chain, etc.  But on the whole, it shows what processes are necessary to accomplish the company's goals.  Next, the information viewpoint, mirrors the process pattern but with a specific perspective on information.  It captures how information flows around the company to help achieve these processes.  A services architecture establishes a high-level, centralized view of the services a company has to offer.  It can also help display relationships among these services when combined with the process and information diagrams.

Probably one of the most important ones, in my opinion, deals with infrastructure services, or technology.  I might be a bit biased, since I have seen multiple companies keep acquiring new EA frameworks from older counterparts without streamlining or simplifying.  Regardless, this diagram shows a snapshot of the company's applications and what services each of those applications offer.  In short, here is everything in your toolbox to help you get the job done.

When you combine multiple tools like these, it is easy to see how quickly EA can become disorganized if you aren't careful.  But it's also easy to identify how helpful a well thought-out architecture can be in aiding customers, employees, and anyone else who interacts with the company on a regular basis.

EA872 - Weekly Blog Entry 4

So now that we have the basics of understanding and implementing an EA, how do we profit from it?  that's the subject of Chapter 5 in the Ross text.  There are many benefits of EA we can focus on:  reduced IT costs, increased IT responsiveness, improved risk management, and increased managerial satisfaction to name a few.

As far as reduced IT costs, there are multiple avenues for improvement.  IT operations units includes costs of services, i.e. laptop provisions, the help desk, access to data, email, network capability, etc.  But there are also maintenance costs to consider.  This is the cost of making changes to existing infrastructure as business needs change.  (Ross 93-94)  IT can also become much more responsive by defining an EA.  For starters, business leaders often have less varied technology from in a standardized environment, and so spend less time addressing technical issues.  This frees up time for other activities.  (Ross 96).

As IT is cleaned, companies generally see improved risk management.  First, there is a reduced business risk as systems are up and running more consistently and frequently, supporting business needs.  IT also sees an increased ability to minimize losses during events outside their control, such as outages.  Lastly, and probably most importantly, security breaches can be kept to a minimum.  (Ross 97).

As the increased value of IT becomes readily more apparent, management can adapt practices to realize this value and turn it into bottom line profit.  Managerial practices such as case analyses or project methodology typically help to create value from business silos.  IT steering committees or a formal infrastructure renewal process will help streamline basic processes.  The last stage, though, often involves direct interaction with business leaders:  process owners, business leaderships, etc.  (Ross104-107).

EA872 - Weekly Blog Entry 3

This week's reading was interesting - how to define your new EA model and integrate it into your existing company.  An EA must support a company's strategy to be relevant, plan and simple.  Ross & Co explain how a company operating model is the facet by which a company integrates its processes to deliver its goods to the customer (Ross 27).

An operating model can be broken down into its standardization and its integration.  Standardization refers to how a process will be executed, regardless of who or what is performing the process.  For example, a company might tell a salesperson exactly what process they are to use to get a new sale.  Maybe this is backed by data showing greater success when this process is followed.  Whatever, the case, standardization generally results in greater efficiency and predictability, guaranteeing that a customer will receive more or less the same end product at the end of multiple transactions (Ross 28).  Integration is essentially the linking of the company's efforts across multiple process to make sure customers receive the same service time and time again.  Integration also increases process efficiency,

What I found interesting is that there isn't really one business model where a company strives for utmost standardization and utmost integration.  At least, there are other options and benefits to not doing so.  The four main operating models are as follows:

Coordination (high integration, low standardization)
Unification (high integration, high standardization)
Diversification (low integration, low standardization)
Replication (low integration, high standardization)

While the architecture for a new building is captured in blueprints, enterprise architecture is often represented in principles, policies, and technology choices (Ross 51).  This quote really hit home with me; it explains why EA is so elusive at most companies.  EA itself is simply made up of ideals - many of which can change over time with the culture of the company.  Ross goes on that the core diagram will help managers and stakeholders understand their company's EA.  In order to be effective, the core diagram should consist of at least the following four elements: core business processes, shared data driving core processes, key linking and automation technologies, and key customers.  It's crazy to see how quickly an EA, developed or otherwise, can become confusing and unwieldy.  Figure 3-1 on page 53 of the text shows Delta Airline's core diagram, and I highly recommend you give it a quick look.  Not only does it incorporate these four elements in an easy to follow way, but it also incorporates an operational pipeline - employee resources, etc.

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).

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.