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:
- 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.
- 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
Scott,
ReplyDeleteI completely agree with your premise that EA is currently, still too IT-centric. While we do acknowledge that the origins of EA comes from the technology camp -- and therefore IT-centricity is a force of habit, Enterprise Architecture needs to differentiate itself with other technology-dominant architecture disciplines by equally emphasizing the business architecture side of EA.
On week 10, as we currently discuss gap discovery and analysis towards building roadmaps, it's good to remember the points that you have been making -- that's it's not all about technology. Indeed, much of the capability gaps that we discover, are actually competency gaps, and primarily comes from the non-technology side. Technology, while it can bring a game-change, is ultimately just a set of tools to enable the development of the primary competencies needed by the organization, in order to remain sharply competitive.
For some examples, we come back to previous competency discussions: Values-based competencies are cultural behaviors aligned upon the type of company the organization wants to be. Leadership competencies are unique sets of competencies that organizations must develop to be strong in execution, motivational energy, strategic decision-making, and communication. Functional Competencies impact organization performance and pertain to defining levels of organizational functions, divisional, departmental, or specific to roles.
Thank you for emphasizing these insights.
/