SOS: EA Stuck - Elephant In The Room

This started as a comment post, but felt it's important and deserves a lengthier discussion. And thus the blog.

When presenting EA initiatives there will be those in the audience who acquiesce, and there will be naysayers. I think there have been many discussions on how to promote these initiatives, as well as techniques to deal with known challenges or pushbacks. Pushback should come at no surprise, since enterprise architects are agents of change, and as such, in some eyes, represent a threat to the status quo, particularly when the organization is too comfortable in it. Culture can be such a powerful force that can counteract and resist initiatives for change, no matter how good the initiative, or how brilliant the strategy. As Peter Drucker points out, "culture eats strategy for breakfast."

But before we dismiss these issues as par for the course, there's one  "elephant in the room" that we also need to address and put out in the open. The sensitive issue of "corporate politics", "turf wars", and other dysfunctions, needs to be brought out, since these can act as road blocks to change.  These I think, in many places, is a never ending dynamic that cause toxic fumes to suffocate the organization, and ultimately draws out circus caricatures. EA's initiatives will be dead on the tracks when architects get caught in the cross-fire, or worse - directly embroiled in these conflicts, and EA becomes part of the problem. As we have noted in class, these organizational issues create silos, and these silos smother collaboration and productivity, drive people crazy in their frustration, and ultimately puts the company mission and goals in danger.

Surely we've all seen this. For the most part of my consulting career (from days of Apple IIe and IBM360), I've been inside quite a very long list of organizations -- some excellent, some less so, some big, very big, small, and very small; some very popular global companies, and some quite obscure. And it happens equally in any of the verticals e.g. banking, insurance, manufacturing, healthcare, and yes, even wicked-smart technology companies. So it's definitely not limited to EA vs. IT vs. Business, e.g. the list goes on with the folks from Quality vs. R&D, vs. Finance, vs. Production, vs. Marketing, vs. Sales. Admittedly, it appears to be the nature of the beast. And while even excellent companies are not perfect, they do tend to show a lot of "perfect moments". For the others, sadly, these perfect moments are spare, if not elusive.

The Nature of the Elephant.
Hopefully, it's only limited to resource contention, since this is less of a challenge than all other reasons. Otherwise, it's best to hunker down for a protracted solution when these silos, turf wars, and dysfunctions are caused by deep political rivalry, seemingly juvenile personality clashes, and deep irreconcilable biases. I hesitate to say "irreconcilable" but there are cases indeed when it is veritably so, and almost impossible to reconcile -- short of a god-like intervention.

Patrick Lencioni has written best-sellers on dysfunctional organizations and teams, and sums up the five main dysfunctions as shown below, and points out the usual manifestations. Note that the lack of trust - that thing that we talked about in class, serves as base for all dysfunctions.

image source: http://minglam.blogspot.com/2014/10/the-five-dysfunctions-of-team.html


Resolving Dysfunction.
According to Lencioni, we can start by building trust -- as was also pointed out in class. We do this by having the courage to open up and having a sort of  "vulnerability" to take good risks on people -- i.e. generous in giving the benefit of the doubt.  Trust allows other people to speak up without fear of retribution, and thus foster healthy debates. Healthy discussions lead to more ideas, which result in more confidence in the decisions made, and thus a higher degree of buy-in and commitment.  Higher commitment makes it easier to take accountability, and a strong system of accountabilities creates a reliable system of metrics with which to measure results. By doing so, the organization can strengthen its culture, and in turn transform confusion and in-fighting into clarity and alignment.

image source: http://ianchadwick.com/blog/the-five-dysfunctions-of-a-team/


The Culture of Nice.
It's also good to note that the principle of "being nice" also applies. But it only really makes sense when everyone is nice to everyone else - as a cultural practice, and not just nice to people in their own turf, or only nice to people they want to be nice to. Thus being nice actually translates to a higher principle - the principle of "Diversity". More and more, global competitiveness ultimately requires embracing this concept, and more so the practice of such. Those who remain parochial will be far from the hall of legendary companies, and to one degree or another, will be left in the margins.

Leadership and "Adult Supervision".
On a lighter take, I would think that this phenomenon is often closely analogous to juvenile pettiness, and as such, can perhaps be solved by better "adult supervision". True leaders who can command respect will be able to gain consensus and move the organization forward into a happy stable future.  For those at the grassroots, we can promote and uphold excellent leaders by supporting those who truly matter to the survival of the company. Moreover, if we are genuinely committed to saving the ship in which we float, we need to neutralize those who are merely political sycophants, mainly concerned with their own self-preservation and the advancement of their individual position.

Conclusion - The Good Politics.
My blog posts so far appears to be assuming a theme on leadership - and I suspect rightly so. Looking at the bright side, there are a lot of good people in most organizations, who are enlightened and well-meaning. Not all of the notions of politics are bad --  and the good side of politics can be used to facilitate healthy consensus building towards strategy execution. We can only hope that those in management who are well-meaning, will also master the good political skills, enough to survive the political jungle, and are enabled to pursue the good things towards company mission.

EA can play a role in organizational leadership. With its mission to bring big picture clarity to the organization, it can help transform the culture by enabling genuine diverse collaboration and team esprit d'corp, in order to successfully execute on strategy.

So there we have it. It can be a messy topic, but it's good to discuss how the sausage is made from time to time.

The Beloved Enterprise Architect's Journey to the C-Corridor

An EA roadmap, to my simplified mind, is akin to a circuit-breaker map.  Nobody really cares where that map is.  That is -- until the lights go out, or you want to expand the circuitry.  When things need fixing, and everyone is groping in the dark, THEN they yell "Where's the map-maker"?

Mike Rollins paper (Enterprise Architecture is More than Engineering, 2008), in the section "When EA isn't working", creates a lot of empathy for the enterprise architect. I myself come from a more project management role, and understand why the project team feels sad when they see that the architect, enterprise or domain-specific, is at a loss and therefore vaguely useful.

Moreover, as an analogy useful to my mind, I imagine that an enterprise architect is like a jungle guide. When the jungle to be traversed is fairly small and familiar, the expedition might choose to say "We don't need a guide...  this is simple enough." And thus, in certain organizations, the EA team -- if ever they were created as such,  can sometimes feel unloved, under-utilized and under-appreciated. However, when the jungle is fairly complex -- markedly so when earlier attempts to cross without a guide has failed, then the expedition grows wise with a more mature decision-frame, and can now see the true value of the jungle guide - the so-called middle-man, who becomes their human bridge who they will come to rely on to take the expedition from this side of the jungle to the other side - their destination.

At this point in our own learning journey, we continue to understand the breadth of responsibilities of the enterprise architect. More and more, this middle-man's role appears to overlap many of that for the CIO, and even the CTO.  It appears that this is no longer a unique observation, as I come across more articles getting the same feeling -- and just a feeling at this point, in the absence of better articulation.  In my opinion, the difference between a CTO and a CIO is easier to define i.e. a CTO typically develops technology products for its external customers, and the CIO typically develops IT capabilities for its internal customers in the organization.  On the other hand, the roles of the CIO and the CEA are largely overlapped.  I think a CIO managing an IT group in a smaller company, can have the extra bandwidth to handle the EA role, and thus play the CEA role as well. And in a really small company, may wear the two hats with an EA staff of zero.  Obviously for larger companies, the CIO would have a full-plate managing IT operations and development, and in this larger context, the CIO can still wear the CEA hat -- possibly with a small EA staff. 

Now for really large companies, particularly with global operations, a C-level enterprise architect - the CEA role is clearly viable, and whose office, I would think, would be mainly dedicated to promoting communications for business strategy execution, with the primary mission of maintaining optimal stakeholder engagement and senior management support for IT initiatives.  In this setting, the Chief will most likely assume the role of champion for the best practices of Change Management in the organization. When the CEA is recognized as such in the organization, the CIO can actually focus more on successful execution of IT operations, and ultimately the EA role becomes beloved.

So who reports to whom? I think this is a result of a combination of elements, e.g. corporate philosophy, point-in-time organizational needs, and -- as our good professor has hinted in class this week, political positions, strength of leadership, personality and qualities in character. Meaning, it's possible that a CIO and a CEA is at the same level, or the head of EA reports to the CIO, or the CIO possibly reporting to the CEA.  And thus when the EA team's role is clearly defined, and has a strong leadership that deserves C status, the corridors to the so-called C-suite becomes a natural placement.

Okay, that's it for this week. I need to get to snow-removal mode, and I have those ibufropen tablets ready. 

Ian

Here's an interesting set of readings below. 

Note that Adrian gives himself the title "Executive Enterprise Architect" - not a CEA, and not surprising for high-level EA consultants, with more advisory rather than staff functions.

Gregoriu, Adrian. The Fading Role of the CIO. http://www.ebizq.net/blogs/ea_matters/2014/04/the-fading-role-of-the-cio.php

Gregoriu, Adrian. (May 28, 2014). The new role of the CIO in the Cloud era.

https://www.linkedin.com/pulse/20140528012251-4427837-the-new-role-of-the-cio-in-the-cloud-era

Luisi, James. (Mar 15, 2014). Pragmatic Enterprise Architecture: Strategies to Transform Information Systems in the Era of Big Data. Morgan Kaufmann.

How we used EA principles without the labels.

The Enterprise Initiatives Back in the 90's, I worked as a data architect in a large project which included the system conversion initiative for the Loans Management System of the Social Security System agency in the Philippines. This was undertaken from 1993 through 1996, and involved upgrades to hardware, software, and database design to support the agency’s services provision at all servicing locations nationwide. The project is a multi-vendor engagement, to include IBM, and Digital Equipment, and the local consulting firm Strategic Partners. The SSS-LMS conversion initiative is a strategic project with a project mission aligned to the agency’s overall mission and strategic objectives. The project’s goal was to transform and improve benefits services for the SSS members, specifically loans provisioning and administration, and to be especially responsive in times of emergency and calamity assistance. Although the term "enterprise architecture" was not in vogue at the time, it is now clear to me that we were effectively following EA principles, and the projects were successfully executed because the agency was strongly operating with a notion of an EA framework with which the IT architectures were developed, and from which governance for IT projects were based. Why the Enterprise Context was important. Clearly, we must have operated with a coherent Enterprise Context in place, in which the agency has developed a clear vision of its strategic business objectives in line with what it has identified as its business drivers in the face of economic trends and challenges. The organization had a clear big picture of its context, identifying all stakeholders, their concerns, and their relationships to each other. The enterprise context was  developed as a result of the activity for "Strategic Planning for IT Development", and included the set of anchor models along with narratives which were compiled in a substantial document.  This documentation provided a consistent view of the organization – a context for common understanding, language/terminology, and an important basis for communication.  It provides a “big picture, enterprise view” which facilitates understanding of what needs to be done, and why the organization has to do it, and becomes a reference which promotes buy-in for senior executives. The big picture context allows the organization to see major components sufficiently to identify capability gaps, as well as unnecessary redundancies in its operations.  As an overall view to which the organization has signed-off, the enterprise context and its set of models become the anchor which serve to be the foundation on which the future-state architecture, with its other derivative models (business, information architectures, business capability portfolios, etc.) are developed.  This story illustrates that a well defined enterprise context is a factor which allowed the organization to evolve their enterprise architecture over time, and execute to deliver IT solutions which are highly integrated with their mission. A Strong Foundation for Project Execution. As per definition argued by Ross, et al (Enterprise Architecture as a Strategy), our projects were operating on a strong foundation for executing the agency's strategy.  The organization had a clear operating model which delineates the necessary level of business process integration and standardization needed to meet its objectives. The organization was equipped with a set of enterprise architecture views that represent the organizing logic for developing business process, information provisioning,  and its IT infrastructure, towards building the organization's capabilities to meet its objectives. And lastly, the organization has been using an  IT engagement model centered in a deep-seated system of governance, with clear protocols for decision-making in order to ensure that IT solutions and projects are optimally aligned with its strategic goals and objectives. With this solid foundation for execution,  the SSS-LMS project met all of the primary objectives set out for the initiative.  As a result, customer service for the agency’s membership have all improved because of the system upgrade.  Loan servicing became faster, cutting the time from application to loan disbursement to one third of the original time during the first year.  The efficiencies of the new system provided operational savings of at least 25% on the first year of implementation.  Monthly service request completions are now better tracked and further automated for measurement and notifications.  And the same efficiencies have reduced the time to monitor delinquencies and track dunning correspondence and collections. The Benefits of an Enterprise Architecture practice. EA systems-thinking certainly helped our projects. EA provided the use of frameworks for doing the project initiatives from a perspective of systems thinking. With such perspective the project team and the client organization was clearly made aware that components of the project portfolio are all related, and changes in one aspect must be assessed for impact on other areas.  It was important for us to understand that the project is part of a bigger picture, influencing, and being influenced by other entities both internal and external to the initiatives. This clarity facilitated by EA principles allowed the organization to simplify their decision-making requirements. EA gave a governance framework to communicate project requirements with stakeholders. It is an imperative for project survival to know the stakeholders and manage their expectations. As argued by Philip Allega, we practiced the principle of "Just enough, just in time", in which we showed early meaningful results to maintain the strong perception of a moving project, in the face of many complexities and project obstacles. EA and its principles facilitated these perspectives, and simplified the assessment of risks that certain stakeholders bring to bear to the project, as well as enabled project support that others can provide as champions. EA provided the framework to review and promote standardized processes and procedures in the organization. This focus and assessment of standards allowed increased operational efficiencies, and helped make things very clear to everyone in the organization, which in turn improved the quality of communications. EA processes helped facilitate the review of the way the organization does things, and provide assessments, and a system to introduce improvements.