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.