Hidden Costs / Hidden Factory

It seems one of the more common refrains within EA is the need to eliminate redundant applications and associated processes.  Every day at work I am reminded of my company’s own redundant applications and wonder why they were allowed to live on.  I’ve decided it must be the cost associated with retaining the legacy version(s) simply cannot be seen; they are too well hidden.  It’s these hidden costs that I want to explore more deeply, with the hope that I can create a sharper message for eliminating redundant applications up front before it’s too late.

Gartner’s IT Glossary (n.d.) defines total cost of ownership as a comprehensive assessment of IT or other costs across enterprise boundaries over time. For IT, this includes:

• Hardware and software acquisition (hard cost)
• End-user licenses (hard cost)
• Management and support (partial allocation)
• Communications (partial allocation)
• Opportunity cost of downtime, training and other productivity losses.

The hard costs are easy to determine and should encompass licenses and initial setup, data migration and the like.   The allocations are harder to calculate but still relatively easy.  The opportunity costs are the hardest to calculate, and many organizations may not even try.  However, when forced, some reasonably defendable calculation can probably be devised.  These costs are all visible costs, although it could be argued that the opportunity costs are somewhat hidden because of how difficult they can be to calculate.

Naturally, redundant applications have visible costs and hidden costs.  The visible costs will frequently drive decision making, and, to be a bit cynical, since so many businesses seem to have redundant applications, the visible costs must not be compelling or painful enough to motivate businesses to get rid of them up front.  The decisions to get rid of redundant applications seem to come after years of painful experience.  Maybe if we can understand the hidden costs better, we can change the decision-making dynamic.

Redundant systems require training that is more complicated, longer, and harder for staff to learn, and it requires operational staff that can handle the same processes two different ways (I say the same processes, because the inputs and outputs are the same, it’s just that everything in the middle is different).

This leads to productivity issues, which, if we were so motivated, could probably be quantified.  However, where things really break down and the hidden costs soar, is with the resulting quality issues.  The Lean Six Sigma (LSS) world defines the hidden costs associated with quality issues as the “Hidden Factory”, describing these hidden costs as overhead which is smoothed over or thrown together with other costs, making the cost of the quality defects difficult to identify (SixSigmaTutorial.com, 2011).

These hidden costs still don’t have much meaning or definition to them, so I’ll try to address that based on my observations.  When quality becomes a problem, the following bullets start to frequently repeat themselves.

• Large amounts of time are spent addressing customer complaints (and some customers are lost).
• Large amounts of time are spent writing internal emails describing what happened and why.
• Numerous meetings (from executives on down) are held to discuss why quality is suffering.
• Tasks forces are established to identify the most acute quality problems.  These meetings are often notoriously unproductive and involve raised voices and lots of finger pointing.
• Teams of subject-matter experts are assembled to analyze what it will take to retire one of the redundant systems.  They will likely conclude that they do not have the time, so the downward cycle continues.
• In addition to the external, customer-oriented quality issues, there are numerous internal quality issues which also lead to time-eating emails, investigations, meetings, and improvement initiatives.
• Inaccurate management reporting due to the multiple systems.
• Greater likelihood of IT support failures which will lead to Operations not being able to get their work completed on time, overtime, upset employees, and hurried work that will likely lead to more customer quality issues.
• Finance has redundant invoicing processes, making it tough to keep the books balanced, which requires them to spend a lot of time with IT and Operations conducting investigations into what work was actually completed.

All of the above fit the definition of hidden costs or the LSS term of “Hidden Factory”. Naturally, these costs are never part of the up-front decision to retain a redundant application.  There are methods for measuring the hidden costs associated with quality problems, which I hope to explore in a future posting.  For now, I hope EA teams can start to craft a sharper message, urgently warning of the hidden costs/factory up front, rather than relying on years of painful experiences to force a decision to eliminate the redundancy.

References

Gartner. (n.d.). Gartner IT Glossary. Retrieved from http://www.gartner.com/it-glossary/total-cost-of-ownership-tco

SixSigmaTutorial.com. (2011). What are Hidden Factory, Cost of Quality? Retrieved from http://sixsigmatutorial.com/hidden-factory-the-two-types-of-cost-of-quality-visible-and-hidden/113/

It’s Not All About Technology - Part 2

In my previous blog posting, I wrote about how EA focuses too much on technology despite all the guidance that tells us EA should not be IT-centric.  This week I’m going to continue with that theme, having been motivated by Gartner’s article entitled “Making Technology Standards Work” (Gartner, 2006).  I want to use this article as further evidence that EA is too technology and IT-centric.

It this article, Gartner acknowledges a frequent complaint heard from the world of EA is that enterprise technology standards are resisted and often not adhered to.   I have heard this many times in my career and have also lived it while working at GM, where enormous energy was spent on defending technology standards.   What concerned me about the article is the focus on technology standards when the loudest complaints from EA should sound more like:

• Why can’t we get different business units to cooperate on standardizing business functions?
• Why can’t we eliminate multiple points-of-entry for critical data?
• Why can’t we eliminate redundant end-user applications?  

These kinds of questions pertain to business complexity, which I contend is more significant than technology complexity.  When distinguishing technology complexity from business complexity, I believe that end-user applications represent business complexity, while the architectural building blocks of the end-user applications represent technology complexity.

• Technology complexity is caused by excessive or non-standard building blocks pertaining to infrastructure hardware/software, not end-user applications.  This leads to more complex support requirements, which leads to a higher cost of ownership.

• Business complexity is caused by many factors from the number of products or services offered to customers to redundant business functions, which is often caused by redundant end-user applications.

Consider two scenarios:

1. A project team wants one or two deviations on the enterprise technology standards (e.g. they want/need to use MySQL instead of the enterprise standard database which is Oracle) but is diligently engaging other business units to make sure that certain business functions are commonized on the same software and data.  
   
2. A project team is fully compliant on technology standards but claims it cannot find the time to engage with other business units (as they will miss their deadlines) to ensure certain business functions are standardized on new software.

I would hope most of us find the latter to be of greater concern than the former.  To reinforce this point, the consulting firm McKinsey & Company (n.d.) surveyed both executives and employees (two to three level down), asking their perspective on their company’s complexity.  The executives focused responses on the scale and scope of the company, the design of their organization, and new legislation.  Employees talked about unclear reporting lines, hazily defined accountabilities, and inefficient internal processes.  Technology did not come up, which isn’t a surprise because IT people were not the focus of the survey.  Unless IT people are the ones being surveyed, technology complexity will likely go unmentioned, which is my point.  EA should simply be careful to show appropriate concern for the complexities that matter to the business.

It is, of course, necessary for EA to promote, support, and defend technology standards.  When a project team requests a deviation, it increases the enterprise’s technology complexity which must be scrutinized.  My only concern is with EA teams being IT-centric and thinking their mission is to focus on technology standards when business complexity is more harmful to the enterprise.  It is business complexity that should be the ultimate focus of an EA team and the target of our loudest complaints.

References

Gartner. (2006). Making Technology Standards Work.  Retrieved March 15, 2016, from Penn State’s EA-872 class materials.

McKinsey. (n.d.). How do I the complexity in my organization?  Retrieved from http://www.mckinsey.com/~/media/mckinsey/industries/chemicals/our%20insights/organizing%20to%20enable%20the%20shift%20from%20volume%20to%20value/how_do_i_manage_complexity_in_my_organization.ashx

It’s Not All About Technology

I came across a common EA definition using the “city planning” metaphor, which caught my attention.  Here is the definition, as offered by Anna Mar (2011):

An Enterprise Architect is like a city planner. A city planner sets building codes and plans common services such as roads and water. Enterprise Architects do the same thing for technology.

I’ve seen this analogy before, but in this instance, it was the last sentence that caught my attention, where the claim is made that Enterprise Architects do the same thing as city planners, just with technology.  The focus on technology seems a bit off target.  In the book, Enterprise Architecture Good Practices Guide (Schekkerman, 2008, p. 31) we learned that the major elements of an enterprise are people, processes, business, and technology, so it seems like an oversight, ignoring people, processes, and business in an EA definition.  Yet another example of how EA is limited to technology out of convenience (I think it makes it easier to define) and out of custom, as it seems most EA practitioners have technology backgrounds.

In our EA872 class sessions, people have commented on how EA at their company is IT-driven, run by the CIO, and seems more like a technology planning committee, which we, as students of EA, have been cautioned against.  

Would it not make sense for an EA team that is functioning in the true spirit of the enterprise to be as involved with non-technology change as it is with technology change?  For example, my current employer recently decided to move the back-office operations of a subsidiary business from the subsidiary’s headquarters in Virginia to the enterprise’s headquarters in Michigan.  This was a big change, definitely a change to the enterprise’s “architecture”, and yet there was no technology component to the change.  The subsidiary company uses their own systems, with their own processes, and that didn’t change.  This particular form of change was strictly about people and how to optimize staff at the different subsidiaries who perform similar functions.  

I hope it’s realistic for EA to take the lead in identifying and championing non-technology change.  The following 2013 article from InfoWorld titled Enterprise architecture shows its business value, briefly describes four EA success stories.  Three of them are clearly all about technology, but the one from The National Bank of Abu Dhabi actually sounds like a success story that isn’t all about technology - I hope I can find more of these stories over time.

References

Knorr, Eric. (2013). Enterprise architecture shows its business value. InfoWorld. Retrieved from http://www.infoworld.com/article/2612515/enterprise-architecture/enterprise-architecture-shows-its-business-value.html

Mar, Anna. (2011). How to Explain Enterprise Architecture To Your Grandmother. Retrieved from http://simplicable.com/new/how-to-explain-enterprise-architecture-to-your-grandmother

Schekkerman, Jaap. (2008). Enterprise Architecture Good Practices Guide. Trafford Publishing.