Adaptive Leadership in EA

Andy Blumenthal wrote a great post “Adaptive Leaders Rule the Day“. In his post, Andy reviewed a Harvard Business Review July 2009 article “Leadership in a (Permanent) Crisis” and commented on the article’s insights on adaptive leadership.

I really liked Andy’s quote Leaders need a proverbial “toolkit” of successful behaviors to succeed and even more so be able to adapt and create innovative new tools to meet new unchartered situations.”

Andy listed some of the successful behaviours in the “toolkit”.  I recommend you read the full article to get all of Andy’s insights. 

Here is the list of successful behaviours:

  • “Foster adaptation”
  • Stabilize, then solve
  • Experiment
  • “Embrace disequilibrium”
  • Make people safe to question
  • Leverage diversity

Taking a similar approach to my previous post on Generative EA Principles, I will explore and share how Andy’s list of behaviours fit with our EA practice (and maybe yours).  We have a long way to go to fully leverage the successful behaviours but having some clear names for what we have accomplished helps.  Thanks Andy!

Foster adaptation: leaders must develop ‘next practices’ while excelling at today’s best practices.” In 2005, we established the Strategic Practices groupin our IT Services department. This group role is responsible for the development, maturation and integration of a broad set of IT disciplines and methodologies across all areas of IT Services. These disciplines are intended to raise the level of rigor and reliability of all of our technical implementations while ensuring that IT investments are aligned with institutional strategy. The Strategic Practices group includes practices like enterprise architecture, business analysis, project management, business continuity, IT security, risk management and performance management. Think of these as our ‘next practices’.  At the same time, we adopted the IT Infrastructure Library (ITIL) framework for standardizing, managing and measuring our core service delivery. So far we have implemented the Service Desk function, Incident Management, Change Management, Problem Management, Asset Management and are building out Configuration, Capacity and Availability Management processes. These are today’s best practices.

Stabilize, then solve: “when an emergency situation arises, first stabilize … then adapt by tackling the underlying causes” Let me relate how we used an EA artifact to stabilize a production performance issue and then how we got to the root cause. In the spring 0f 2007, we began to receive complaints from our ERP clients that performance was degrading and it was impacting their ability to work. We gathered a team of technical experts with skills from the desktop, application, servers, storage and network teams. After a day and a half of investigation, we were no closer to a solution. In fact, everything looked to be running fine except for the constant client complaints. Next we started to get complaints about slow performance on our email system.  One of the first artifacts we built for our EA practice was an Application Portfolio which contained over 200 applications and key attributes about each one.  By referring to the Application Portfolio, we queried the attributes of each application: ERP and email. We found two architecture components that were similar 1) the P Series server and 2) the Storage Area Network (SAN).  The team focused on these two components and found that there was a mis-configuration on the SAN causing it to dynamically switch logical volumes between physical disks.  This caused the performance issues in both the ERP and email systems. We brought in the SAN vendor and corrected the configuration resulting in a permanent fix to our performance issue.

Experiment: “don’t be afraid to experiment …”  Having a place in our enterprise architecture to foster experimentation and research is essential. Part of our EA taxonomy is the clear articulation of a Technology Lifecycle. Our technology lifecycle contains the following phases : Watch-R&D-Invest-Sustain-Contain-End of Life.  Being clear about the R&D phase and putting success criteria in place helps us evaluate new technology and make concious choices to stop working on technologies that don’t meet our success criteria and to adopt/invest in technologies that deliver value to our organization.

Embrace disequilibrium: “often people … won’t or can’t change until the pain of not adapting is greater than the pain of staying the course.”  This is a tough one.  Finding the sweet spot that people are willing to be open to change is really a difficult thing – timing is everything. We do not do a good job of this at all.  In the past, we just lived with the pain and continued to apply small fixes and patches to avoid changing. The result was an enterprise architecture that was made of dated components and unnecessary complexity.  In the past 2 years, the pendulum has swung the other way and now we are forcing our people into constant change just to get caught up. The result of this is exactly as Andy says “people fight, flee or freeze”. This is never a good situation and has forced us from a planning perspective to re-trench and work on organizational change management by building plans collaboratively with our teams and our clients. More work to be done here.

Make people safe to question: “create a culture of courageous conversations”  Being open to new ideas, alternate solutions and constructive criticism is essential for an adaptive leader like an Enterprise Architect. The challenge is to create a forum that encourages the conversations but avoids the typical “technology wars’ that inhibit solutions and can be destructive.  Our approach to address this issue was to create a solutioning process for consistently providing solution architectures for requests that involve a technology service. In the past, clients would receive different solutions based on who in our department they took their request to.  The result was that for requests with essentially the same requirements, clients could receive up to 4 different solution architectures.  Talk about adding complexity to our already complex world!! 

As part of our solutioning process, we created a Solutions Council; made up of technology domain experts in IT Services.  All requests are consistently funnelled through our Service Desk Incident Management system, written up by the client with assistance from a business analyst and then reviewed by the Solution Council weekly.  The Solution Council reviews are vigorous and at times challenging. The discussions put a focus on client requirements and how we can sustainably support them. In the end, we come up with a recommended solution architecture that respects our EA Guiding Principles and can be supported in our IT Service Management environment.

Leverage diversity: “the broader counsel you have, the better decision you are likely to make” What do you do to ensure you get input from staff and managers; students, faculty and support staff, line workers and executives; employers and government?  In 2007, we began an annual proces to build a 3 Year Technology Plan for our organization. As part of the plan, we solicit input in several ways.

1) conducting interviews with senior leadership to clearly understand their issues, challenges and vision for the future of their areas

2) conducting technology reviews of our major architecture components from network, storage, servers, data, applications and presentation with input from our vendors 

and

3) conducting environmental scans for targeted business and technology areas like Strategic Workforce Planning and Cloud Computing by consulting our peer organizations like Educause and leveraging services like Gartner. Recently, I have also been able to leverage the power of Twitter to get excellent advice and peer reviews from around the world. 

We update the plan annually so that we always a have a 3 year sliding window into the future. Soliciting input from all our stakeholders ensures our plans are aligned to the strategy and goals of the institute.

Through this post, I tried to show where our EA practice has lived up to adaptive leadership and also where we need to improve. I hope this post will stimulate more conversation and encourage you to look at what behaviours you leverage in your organizations.  Thanks Andy for your post!