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.