Topic 2: Enterprise Application Architecture

Since the topic for this blog posting is Enterprise Application Architecture and since the title of this blog is Enterprise Architecture for SMBs, it seems fitting to analyze one of the critical elements of an Enterprise Application Architecture, that being SOA, for small and medium sized businesses.

Reflection 1: Small and medium businesses: We simply don't need SOA

The first article which I want to reflect on explores the position that SOA isn’t necessarily important for SMBs.  The reason offered is that SMBs do not have the application complexity and diversity that large enterprises have.  I currently work at a $60 million business which has two primary lines of business.  Each line of business has a primary back-office system (one is custom-built, the other is commercial) along with shared commercial finance and CRM systems.  That’s about it - definitely not complex, so the article has my attention.

The article references an informal survey of mid-market CIOs which reveals that two-thirds feel there is no business need for SOA at their enterprise.  This opinion may be due to an overall simpler IT environment that “works” or it may be due to limited resources (people and budget).  Whatever the reasoning is among these CIOs, I think the informal survey provides an accurate representation.  The article is from six years ago, but having worked at SMBs for the past nine years, I think the opinions expressed in this 2010 article are still holding true in 2016.  

Further into the article, however, the author chooses to pivot from the opinion of the mid-market CIOs and offers some of his own reasoning on why SMBs should care about SOA.  He says:

Of course, the mid-market is the prime candidate for cloud computing, and this is where the value of service orientation will ultimately be realized, on an enterprise-to-enterprise scale. But for applications within the infrastructures of smaller enterprises, SOA is still beyond reach.  

Still, the more a business of any size can service orient, the better. SOA is an extension of enterprise architecture, and EA is important at any level.

I’m in agreement with the author and I think the first paragraph above is very telling.  Even six years after this article was published, I can attest that for many SMBs, running a solid, well-managed data center is beyond their capabilities.  With the data center yoke around our necks, the notion of implementing a service-oriented architecture is accurately stated as beyond our reach.  We need to get out of the data center business, move to the cloud, and then start innovating with our Enterprise Application Architecture.

Reflection 2: How Can Small to Medium Sized Enterprises Benefit from SOA?

For my second reflection, I want to remain on topic with SOA at SMBs and get some additional perspectives on why SMBs can, and should, move to a SOA.  The article being examined is actually a series of responses to the question “How Can Small to Medium Sized Enterprises Benefit from SOA?”.  Most of the answers lack substance and depth, but there were a couple of comments that I found very relatable.  In the posting from John Power he states the following:

However, from my perspective the real benefit to SMBs is the possibilities it offers them to integrate their systems with large customers or suppliers.

This struck me in two ways.  First, it struck me for its accuracy.  It has been my experience that invoking a few web services and standing up a few of our own in order to integrate with our suppliers and partners is exactly what many SMBs do for their SOA initiatives (without going much further).  

The second manner in which it struck me was how it reinforces the confusion and hype around SOA.  Integrating with a handful of external businesses through web services in no way constitutes the deployment of a broad service-oriented architecture.  However, I will state that those simple external integrations are extremely valuable to SMBs and they work well, leading many CIOs, I reckon, to conclude “that’s good enough for us”.

The other posting that caught my attention was from Kelly Emo.  She states the following:

Secondly, SMBs will find themselves brought into the SOA world whether they explicitly plan for it or not. Packaged apps and SaaS solutions are rapidly evolving to be architected based on the concept of loosely-coupled shared services...

This claim is also very accurate in how it matches my SMB experience.  It is the packaged applications and SaaS solutions which SMBs utilize, that essentially forces them to eventually learn and leverage the service orientation built into those commercial offerings.  

It seems the ultimate takeaway for me is that SMBs will adopt SOA gradually (even glacially) and very deliberately, avoiding big-bang transformations.  If resistance persists, then, to the point made by Kelly Emo, SOA will likely start deploying itself in the enterprise.

Reflection 3: It's Time to Retire the Concept of the Three-Tier Application

The third article I want to reflect on comes from the Lesson 2 reading material for EA-874.  This article seemed like it would be a fitting cap to my SOA-themed blog post.  I expected the article to largely espouse the virtues of service-orientation for building applications. In other words, the author just wants us to replace the traditional locked-in business logic of the middle tier with services that can be invoked throughout the enterprise.

The author quickly reminded me, however, that replacing the locked-in middle-tier with services still leaves us with a three-tiered application.  So, my assumption about the article was wrong and I was suddenly wondering what new trend all the SMBs will be lagging behind on now.

It turns out the author is not actually recommending that we retire the three-tiered separation of concerns between user interfaces, business logic, and data access.  He, in fact, states that we need to continue reinforcing the three-tiered separation of concerns.  All the author is saying, as a natural evolution after implementing a SOA, is that the user interfaces of applications should no longer be homogenous and monolithic - they should be a collection of components supporting many devices.   These user interface components will invoke many business services, and these business services will invoke many data services.  

Keep in mind that all these pieces are still to be architected with the separation of concerns being resolutely applied.  We just need to stop thinking about single applications as a homogenous three-tiered stack and instead start thinking about them as a collection of user components and business services that cannot be easy abstracted as a nice, neat three-tier stack.

The bottom line is that the separation of concerns (user interface, business logic, data access) is not going away, but simple, self-contained applications are. All in all, not too big of a paradigm shift for SMBs to work toward...once we start making more progress on our SOAs.

Topic 1: Enterprise Information Technology Stack

Reflection 1: On layers in enterprise-architecture

Since the first lesson for EA-874 is an introduction to the enterprise architecture stack, I thought it would be worth taking a closer look at the different stack depictions among EA frameworks.  The above article highlights a few of the differences:

• Archimate’s three layers: Business, Application, and Technology
• TOGAF’s four layers: Business, Data, Application, Technology
• Zachman’s five or more layers (depending on interpretation)

In addition to the article, our Lesson 1 reading material falls in line with TOGAF, while the Gartner EA framework (not examined in the article) puts a twist on the stacked layer paradigm, emphasizing the business, data/information, and technology layers.  Instead of stacking them, Gartner shows the layers intersecting, and it’s at the intersection of the three layers where solutions (applications) are defined and created.

The article rightly points out that while there are many depictions of the EA stack, two layers are consistent: business and technology.  It’s the data/information and application layers that provide the variability.  

While the article fairly contends that there is no right or wrong depiction, I will express a bias for having a data/information layer that is separate from the application layer.  Information should be treated as something that exists in an enterprise regardless of the existence of applications.  It’s for this reason that an information layer is essential to defining an enterprise.

I will further express a bias for the Gartner approach, which shows applications (solutions) not as an EA layer, but rather, as an outcome of the three core layers of business, information, and technology.  The business and information layers should define the enterprise without regard for technology.  When we add in the technology layer, we now have the ability to create solutions and/or applications.  It is the three layers of business, information, and technology that actually define the enterprise.  Once they are established the enterprise can go about creating solutions/applications.

That’s just my point of view.  Once again, there can be no right or wrong, just varying degrees of acceptance or popularity.

Reflection 2: Introduction to Enterprise Architecture

The previous article explored the long-standing differences in EA stacks and their respective layers.  This article goes a bit further and reveals a recent trend for depicting separate security and integration layers, not as part of the stack, but as vertical layers that touch all the horizontal layers of the EA stack.  

I have an easy time seeing why security is being treated as an EA layer, albeit vertical, as all EA layers have unique security requirements which are not all technology-driven, and thus, not addressed in the stack’s technology layer.  Security strategy should be expressed and executed at an enterprise level to ensure that all layers of the enterprise are addressed in a coherent manner.

The integration layer, however, is something I’m still struggling with.  I see integration as part of the technology layer, used to build solutions and enable communication between intra- and inter-enterprise applications.  I’m not sure what the purpose is at the business and information levels.  Keep in mind, my interpretation of the information layer is as a logical depiction of the enterprise’s information without regard for applications, which is why I struggle with the integration layer having pertinence here.

It will be interesting to further explore vertical EA layers throughout the semester as well as in the following article and reflection, where yet another example of a vertical EA stack layer is presented.

Reflection 3: Essential Layers, Artifacts, and Dependencies of Enterprise Architecture

In this last article, the author took four real-world businesses and mapped their actual EA layers to the author’s proposed, or ideal set of EA layers.  The four businesses were intentionally selected from different business domains and different countries to ensure diversity.  

One discovery, maybe not that surprising, is that each business had implemented their own unique layering, definitions, and core artifacts, which can be seen in the respective diagrams depicting the mapping between the subject’s layers to the author’s proposed layers.  The paper is only two and one-half years old (published in February 2014), so it’s interesting to see the custom EA programs at these businesses given the amount of time the more popular EA frameworks have had to take root.

On the surface, these differences don’t seem to mean much as they appear to be mostly superficial preferences in naming and in the grouping artifacts and responsibilities.   It is interesting to read the motivating factors each business had for starting their EA program and to contemplate the impact those motivators had on the resulting custom EA layers and programs even though the article avoids direct cause and effect conclusions.

Let’s take a quick look at how these four real-world EA stacks compared to our Lesson 1 reading and the first two articles from above.  

• Company A comes close to the common three layer stack, forsaking the data/information layer but adding the strategy layer, which I think most EA programs would lump into the business layer.
  
• Company B comes very close to the traditional (and Lesson 1 recommended) four layer stack, but surprisingly, separated out the data/information layer into two separate layers, treating the data layer in the traditional sense of logical and physical data models, while defining the information layer in a unique fashion with a focus on metrics.  
  
• Company C really went custom with six layers.  What I found interesting here is the integration layer, which is depicted in the stack as a horizontal layer underneath the application layer.  Recalling the second article from above, where I was having a hard time with the notion of a vertical integration layer spanning the entire EA stack, this approach by Company C made more sense to me and felt much more intuitive.

• Finally, Company D went with the traditional three layer stack, but also added in two vertical layers, similar to what was depicted in the second article.  One of these two vertical layers represents security, matching the reference from the second article and further reinforcing the concept of a vertical security layer as a trend with EA stacks.

My take-away from all this is that businesses will commonly tailor their EA stack, just as the article’s four companies did, even as certain EA frameworks gain wider adoption.  This tweaking will sometimes be done in obvious ways, by adding or subtracting layers, and also by more subtle ways, by slightly altering the definition of certain layers and what artifacts and responsibilities get grouped into those layers.

Ultimately, the differences come down to each enterprise simply wanting to emphasize unique EA elements while deemphasizing others based on their unique histories and future strategies.

Agile Leadership

The “agile” label has been used heavily in the software development world for many years and is now in vogue for businesses and IT/EA governance programs (and many other disciplines, I’m sure).  This label is meant to describe a trait that all businesses or organizations aspire to be  - responsive, fast, nimble, or in a word...agile.  In essence, “agile” should be as much a leadership philosophy as it is a governance or software development methodology.  If we want our EA programs and our governance programs to be agile, then it’s going to come down to the people - the leadership - to make it happen.  So, what is agile leadership and how is it achieved?

Agile leadership is essentially the antithesis of bureaucracy, and it involves the blending of three major leadership functions that typically suffer in a bureaucratic world; setting expectations, empowerment, and accountability.

• Expectations – What are the results that you or the organization want to achieve? Know what they are and state them.

• Empowerment – Do you have talented, experienced, responsible people?  If so, then allow them to make decisions without seeking approval.  That’s what empowerment is.

• Accountability – If your people know their expectations and are empowered to make decisions, then they must also know they will be held responsible for their decisions.

There may be nothing that will allow an organization to better achieve agility, speed, and responsiveness than the simple actions of setting expectations, empowering the right people, and then holding them accountable.  It also stands to reason that few things will give the people being empowered greater satisfaction. It’s worth pointing out here, the research Frederick Herzberg did regarding job satisfaction (Herzberg, F., 1987) where the top four factors leading to job satisfaction were 1) Achievement, 2) Recognition, 3) Work itself, and 4) Responsibility.

The most important thing to understand about bureaucracies is that they are not out-of-control, uninvited party crashers that ruin businesses.  Rather, they are structures intentionally put in place to achieve a very specific objective – to make sure bad decisions are not made.  The benefit would be great if the costs were not so high.  The price of this desire for near perfect decision making is that large chunks of time are consumed and there is almost no accountability.  When decisions are finally made, after multiple reviews and through the seeking of consensus, the amount of time elapsed often renders the decision irrelevant (or weakened, at best).  Also, who’s accountable?  The answer is largely no one; and when nobody is accountable, progress tends to not take place.

Unfortunately for many, forsaking the stifling and unaccountable safety of the bureaucracy feels risky.  However, for an organization with talented, experienced, responsible people, the risk is easily mitigated.  These people know what needs to be done and how to do it, so to confine them to a bureaucracy is really an absolute shame.  If an incorrect path is taken the sheer speed with which it is taken will usually soften the impact significantly.  In other words failing fast is a lot better than failing slow, or failing through inaction or atrophy (which is the most common outcome of bureaucratic structures).  As agile EA leaders, all we have to do is know our people and empower the right people – the upside in speed and agility, not to mention job satisfaction, will be tremendous.  

References

Herzberg, Frederick.  (1987, Sep-Oct).  One More Time: How Do You Motivate Employees? Harvard Business Review.   Retrieved from http://scholar.google.com/scholar_url?url=https://xa.yimg.com/kq/groups/22741279/1871431599/name/One_more_time.pdf&hl=en&sa=X&scisig=AAGBfm1uUvvj1BuLUUxfm4pTEoVgU2GfjA&nossl=1&oi=scholarr

Diversity of Thought

It seems widely accepted these days that diversity is an asset to a business.  So, how does a small-to-medium sized business (SMB) develop sound IT and business strategies when the leadership headcount is fairly small, IT leadership often is a single person, and there may be a founder-owner who dominates decision making?

I’ve been thinking about this as I reflect on some of the dubious decisions and strategies of my current employer (default management law firm) from the past several years.  Here are a few that dominate my daily existence:

• We chose to build our own back-office case management system (CMS) when there were proven commercial systems available.  We now have a high cost of ownership compared to the commercial systems, without gaining any competitive advantage.
  
• The system mentioned in the previous bullet was built from 2012-2013 as a client-server system, forsaking a web-based solution.  We now experience all of the client-server maintenance issues (400 users spread out geographically) that made web-based applications so attractive to businesses way back in the 1990s.  

• We chose to forsake investing in a subsidiary law firm’s CMS, with the rationale that in the near future, that system would be replaced.  It’s been nearly ten years, and the legacy CMS is still running with no investment in features and automation, which is severely hurting the subsidiary firm.

• Several years ago we chose not to migrate from a legacy system because it was time-consuming for IT and the business to figure out the data migration requirements.  At the time everyone was comfortable and familiar with the legacy system, so keeping it around felt like it would be no big deal.  We’re still paying heavily with quality and productivity issues for what amounted to a myopic decision of convenience.

• A decision was made to build a custom invoicing and check printing system when we already had a commercial accounting system in-house.  This decision was made, again, out of convenience, because figuring out how to interface with the commercial accounting system was considered too challenging.

My intent here is not to cast stones (even though it appears that I am) regarding past strategic initiatives, but instead, it is to show how dubious decisions can be made when there is a lack of thought diversity.

Many enterprises have cultural challenges.  My twenty years at General Motors showed me how the culture of a massively large organization can suffocate change.  At an SMB, change should come more easily.  However, it seems to me that the big risk isn’t enacting change, but rather, it’s with enacting the right change when there is a lack of thought diversity.  At least that’s the conclusion I’m drawing on why so many dubious decisions were made.  Decisions for which a price continues to be paid.

So, what should a resource constrained, diversity-deficient SMB do to mitigate the situation?  Participating in industry trade groups and business associations certainly is a good start.  Creating an advisement board of external resources and finding a similar, but non-competitive business to share and vet ideas with are also good approaches.  Engaging consulting firms (for both IT and the business) for strategy and internal assessments should also be a common practice as it can quickly expose a business to a large variety of choices, across many industries (Bain & Co., n.d.)

Ultimately, the answer to the “diversity of thought” problem is for the business to engage its external environment as much, and in as many ways, as possible.  Business and IT strategies are far too important to trust to so few.

References

Bain & Company. (n.d.). What to expect from management consulting. Retrieved from http://www.bain.com/offices/brussels/en_us/careers/top-management-consulting.aspx

Measuring The Hidden Factory

A few weeks ago I blogged about the hidden costs (or hidden factory, as Lean Six Sigma refers to it) associated with quality problems, which in my case was inspired by redundant software systems at my current employer.  This week I want to continue with the topic by focusing on measuring the size of the hidden factory, or the cost of poor quality.

When we think of what a company does to add value to a product or service for its customer base, we should look at it as if there are two factories at work.  The first factory is the primary factory, or the visible factory, that executes the normal, value-added processes to produce a value-added output.  The second factory is the hidden factory.  This is the factory that kicks into action when things go wrong and it costs a lot more that what people might think.  My posting on Hidden Costs / Hidden Factory from a couple of weeks ago will give some perspective on this.

Essentially, the hidden costs become much more destructive, simply because they are hidden or unknown.  I think business executives would likely agree that when it comes to running a business, it’s the unknowns that should cause the most worry.  As Plato put it “Better be unborn than untaught, for ignorance is the root of misfortune.” So, to avoid misfortune, let’s explore how we can measure the cost of poor quality.

The following excerpt is from a Quality Digest article (Lee, G., n.d.) that examines how a large, global energy company, ABB, attempts to measure the cost of poor quality.

At ABB we use a metric known as cost of poor quality (COPQ). COPQ is measured by estimating the cost of all efforts undertaken in an organization, including materials and processes used in assembling our products, that don’t provide value to customers. In the lexicon of lean manufacturing, these are nonvalue-added activities. At ABB, COPQ is the sum of all nonvalue-added costs divided by the total revenue that’s generated. The resulting measurement is the percentage of revenue that’s lost due to waste.

COPQ is measured, reported, and tracked in each of the business units. COPQ is used to measure progress within the organization and to identify best practices that can be shared throughout the company. COPQ is a metric and a learning tool, helping an organization to understand what’s nonvalue-added and to establish opportunities for improvement.

My first thought, upon reading the article, is how impressive ABB’s measurement capabilities are, given that they can track and report nonvalue-added costs across all their business units.  The article doesn’t say how ABB did that, but the excerpt does provide us the simple math behind their COPQ metric.  We’ll have to devise our own approach for determining nonvalue-added costs.

I think all approaches, as ABB did, should start with total revenue.  That’s easy.  It’s the cost part that will likely be tough, requiring some creative approaches.  Using my current company, a default management law firm, I’m going to explore what I hope will be a reasonably simple approach.  We have no ability to precisely track value-added costs and nonvalue-added costs, so I need an alternative.  Since our legal processors (they’re the hourly Operations staff that does the work to generate the revenue) spend a lot of time on rework and quality issues, I can’t simply take their total compensation costs and treat it as value-added cost.  Plus there is also staff from Operations management, IT, Accounting, and HR that get sucked into our quality problems.  Their labor needs to be reflected in our nonvalue-added costs.

What I will propose is that my company establish a benchmark cost per legal case type. For example, through a bit of analysis, we may determine that a typical bankruptcy costs us $1,000 to execute, an eviction may cost $1,500, and a foreclosure may cost $500.  Since we know the volume of cases for each type, we then know what our value-added costs should be.

If we take the total costs of the Operations department, plus the total costs of the departments that directly support Operations (IT, HR, Accounting) in the execution of our customer value stream(s), we can then come up with our own COPQ formula that resembles the ABB approach.

W = Total costs of Operations plus supporting departments (IT, HR, Accounting)

X = Total value-added cost of all processed cases (based on benchmarking)

Y = Total revenue

Z (nonvalue-added costs) = W (total costs) - X (value-added costs)

With our nonvalue-added costs established, we can then rejoin the ABB approach and compute our COPQ to equal Z divided by Y, which gives us a metric that we can track over time.  We can further refine the total operating costs by doing things such as taking a portion of HR based on the number of new hires brought into Operations versus the number of new hires across the enterprise.  Basically, we want our total operating costs to, ideally, be associated with our customer value stream(s), and not include overhead for such things as Marketing and new business development.

Measuring the hidden costs of poor quality is not going to be the easiest metric to obtain, but it isn’t unreasonable.  If a company really cares about quality and knowing how big their hidden factory is, then finding the motivation to calculate a COPQ shouldn’t be that hard.  Hopefully, the effort will make the hidden costs a little less hidden and decision-making a little more sound, and maybe, just maybe, knowledge of their hidden costs will allow businesses to avoid a little misfortune.

References

Lee, Gerald. (n.d.). The Hidden Costs of Poor Quality. Retrieved from http://www.qualitydigest.com/dec07/articles/06_article.shtml

A Nascent Governance Process

Gartner’s slide deck entitled “The Five Step for Defining Effective EA Governance” (n.d.) inspired me to take a retrospective look (using the five steps as my measuring stick) at the IT governance process implemented by my company last summer.  We’re an SMB with no formal EA practice who’s fighting to survive right now, so this is not meant to be viewed through rose-colored glasses or to be cynical in any way.  It’s just meant to be real-world experience from a company trying to find it’s footing when it comes to the business and IT working together more effectively.

Step 1: Incorporate IT and Corporate Governance Principles

We start off the retrospective a little weak with regards to our principles, which are basically implied rather than expressly written down and promoted.  Right now, it’s like a “do the right thing” approach where we all assume we know what the right things are.  There’s no substitute for writing important things down and there’s little doubt that individual perspectives vary widely, so a set of written principles would serve us well.  We’ll need to work on this area.

Step 2: Identify Your EA Archetype

This is an easy one.  Gartner provides a magic quadrant of governance archetypes where the lower-left is the least capable and the upper-right the most capable.  We’re so new to governance that we easily fall into the lower-left.  Right now our governance meetings tend to be focused on providing status updates on recent IT issues rather than on strategic matters.  Given time and commitment, I’m sure we’ll progress to better quadrants.  I’ll know we’re making progress when we spend less time talking about recent failures and more time on planning for the future.

Step 3: Identify Your Organizational Culture

I feel like we’re doing well here.  The Gartner presentation notes (from The Five Step for Defining Effective EA Governance) talk about how organizational cultures often must change to keep pace with the transformations brought on by EA.  In our case, the current transformation taking place isn’t brought about by EA, but is instead about embracing the principles are EA.  In other words, we’re transforming our culture to one where the business and IT work together to plan for change and sound governance is expected.  Our execution isn’t where we want it to be yet, but our cultural commitment feels real, which bodes well for the future.    

Step 4: Identify Your Governance Style

Our governance style is very much akin to a the business monarchy model, which emphasizes a centralized approach, with a tilt toward business representation, and where the executives tend to make the decisions (Broadbent, M., 2002, p. 4).  Even though we’re a collection of five companies plus three law firms doing business in eight states, our governance is completely centralized.  Historically, we have had a diversified operating model, but we are gradually shifting to a unification model, so our centralized governance approach makes sense.  

Step 5: Match Your Governance Style With Your EA Approach

We don’t have a formal EA program, at least by name, but we operate in a de facto manner as an EA program.  We are a collection of business and IT leaders planning for change, suspending, if you will, your recollection of Step 2, where I admitted we largely spend our time talking about recent IT issues.  Our pseudo-EA approach is definitely traditional, with one centralized voice and direction for the enterprise, which, fortunately, matches well with our monarchy governance style from Step 4.

Conclusion

There’s little about our nascent governance approach that is clicking at this point, other than good intent, which strikes me as normal growing pains.  If we stay positive, diligent, and committed, I’m confident we’ll reach the upper-right of Gartner’s EA Archetype Magic Quadrant (Step 2) in due time.

References

Broadbent, Marianne. (2002). CIO Futures– Lead With Effective Governance. Retrieved from http://unpan1.un.org/intradoc/groups/public/documents/apcity/unpan011278.pdf

Gartner, (n.d.). Five Steps for Defining Effective Enterprise Architecture Governance. Retrieved from Penn State EA-872 L08 class material.

Business Velocity

For this blog post, I want to talk about business velocity, which has been defined in one manner as a company's ability to generate operational speed while heading in the right direction (ebizQ, n.d.). I believe, just like previous posts on complexity and hidden costs, business velocity is one of those hard to see and measure business factors that EA needs to better understand.

The Business Case

This past Friday, I spent some time working on a business case with two representatives from the operations side of the business.  We are looking at automating the submission of invoices for one of our largest clients.  The business folks already had their numbers for how long it takes and how much it costs to prepare and submit an invoice for this client, they just needed some costs from IT for software development, for which I obliged.  The resulting reaction from the Ops folks was basically “eh, not very compelling” followed by “darn, we’re probably not going to do this”.  

The Backstory

The company I currently work for is struggling.  We’re a default management law firm, which means we handle foreclosures, bankruptcies, and evictions for lenders.  As cases proceed, the lenders require us to update their systems so they will always know the status of their loans.  This is very onerous, but it is a requirement for our business.  The default management firms that are thriving today invested heavily in integration and automation many years ago.  They have higher quality, much higher margins, more capital for investment, and the ability to grab market share from us.  We’re playing catch-up.

A Push to Automate

The invoice transaction we were assessing is but one transaction out of hundreds for which we need to update the lender systems, all of them with some kind of measurable average duration.  For the aforementioned invoice transaction, the time duration per submission is three minutes.  Almost all transactions will be in the two-to-three minute range.  Let’s say that, on the whole, we have three hundred unique transactions for updating lender systems, on the average, each transaction takes three minutes, and we have, on average 1000 such transaction each day.  What if by investing in IT automation and integration, we shaved two minutes off each transaction? That would be 2,000 minutes, or 33.3 hours, or 4 FTEs of savings each day.

What struck me about our business case exercise, is that it was based strictly on the transaction time and nothing else.  However, since our objective as a company is to automate several hundred transactions, I started wondering if the productivity impact starts to accelerate as we progress with our automation initiative.  I don’t believe the operating improvements remain constant.  As we automate more transactions, the productivity of the enterprise, I believe, will improve beyond the measured minutes, and will actually start to accelerate beyond the original measurements, however, not in a way that is easily predicted or measured.

My point is simple - the work being automated becomes less tedious, turnover is reduced, which positively impacts HR and managers, training is easier, quality improves, which reduces the hidden factory, talented resources can be better utilized, so forth and so on.  The impact permeates the entire enterprise.  However, I also believe that the remaining one minute of labor per transaction is reduced further from what was originally measured because of the lower turnover, better training, improved quality, and the ability to better utilize talented resources.  Basically, the business velocity is picking up and it’s tough to measure that in a business base.  Hopefully, the initial “eh” reaction doesn’t win the debate.

Conclusion

I’ve blogged about complexity, hidden costs, and now business velocity, which are all very difficult to identify and quantify, yet extremely important to selling the projects that need to be sold.  If EA teams cannot measure these factors, we need to, at the very least, understand them so we can articulate messages that are compelling and influential, rather than mere hyperbole.  For a good metaphor, I suggest reading “How to Break the Log Jam Slowing Your Small Business Velocity” (Nagel, Jackie. n.d.).

References

Ebizq (n.d.). Ebizq Roundtables. Retrieved from www.ebizq.net/series/19.html

Nagel, Jackie. (n.d.). How to Break the Log Jam Slowing Your Small Business Velocity. Retrieved from http://www.synnovatia.com/business-coaching-blog/bid/183334/How-to-Break-the-Log-Jam-Slowing-Your-Small-Business-Velocity