Sunday, July 17, 2016

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



Sunday, July 10, 2016

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


Thursday, June 30, 2016

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.  

Sunday, June 19, 2016

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.

Friday, June 10, 2016

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

Saturday, June 4, 2016

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.