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.

 

Todd Biske asked this on Twitter “What are your EA services? In other words, what are the major functions your EA term performs and/or markets to the rest of the enterprise?”  He followed up with the following Ideas for EA Services:

  1. Architecture Review Service (could be on-demand, could be required)
  2. Project consulting (i.e. act as, or assist, project/solution architect)
  3. Strategic Architecture Services (to-be architecture)
  4. Architectural Reference Services (development of reference artifacts)
  5. Architectural Standards Services (official standards, similar, but more official/specific to Reference Services)
  6. Architectural Research Services

He ended with “What else should be on the list, or what items should be changed?”

We publish a Core Service Catalogue to articulate what our IT Services Department delivers to BCIT. We talk about this as our default service level agreement to the Institute. We currently are on Version 4 of the catalogue.

In the Core Service Catalogue, we included an Enterprise Architecture key core service to help our clients in the BCIT community understand what EA activites are available.

Here is the list of EA activities we defined:

  • Developing, documenting and publishing the Enterprise Architecture for business and technology at BCIT by:
    • continuously aligning technology with changing goals and objectives of the institution
    • providing common language to understand the value IT solutions can bring
    • allowing IT Services to more strategically and effectively support the institution with an agile IT architecture
  • Providing Enterprise Architecture approval as part of project management methodology
  • Providing Enterprise Architecture approval as part of the change management process
  • Providing early guidance to departments by conducting concept reviews
  • Providing consulting and recommendations for delivering technology or process to support business services
  • Establish, implement and publish Architectural Standards
  • Advocating the value proposition of Enterprise Architecture

Now that I have seen Todd’s list and we are hitting the review date for our EA Key Core Service, I will be leading a review of our Core Service Catalogue entry.  I will publish the new version once it goes to production. Thanks Todd for helping us grow the maturity of our EA Services.

 

Mike Kavis posted another great piece on why we should use Enterprise Architecture. As always, Mike has some real gems in his post.  Here are a some:

  • “It sounds to me like people have a technical solution and are now looking for a problem to solve with it.  It needs to work the other way around!”
  • “Well, coming to the business with technical solutions asking for help to justify them with business drivers is not alignment.”
  • “At this point the ROI should be much easier, because the solutions were driven by the problem statement(s), not the other way around.”
  • “Without this alignment, IT will constantly struggle to sell technical solutions to the business and come up with appealing ROIs.”

With the recent economic situation, business leaders are looking more and more to IT leaders to help enable cost savings and business performance. In my regular meetings with my business colleagues, this is becoming a consistent theme. The only way this will happen is for IT leaders to sit with business leaders and understand their issues and problems.  Once this problem is understood, then the  IT leader can bring to bear the appropriate technology solution.  The ROI is put back on the business (where it belongs) and how the problem is solved not on the technology that enables the problem solving.

I am interested in how to get the IT leader to the “table”. Traditionally (and most commonly), business decisions are made with little IT input. We only hear about it after the fact and need to respond.  How do we as Enterprise Architecture professionals demonstrate our value, gain the trust and build the partnerships with our business (in my case education) colleagues?

I have some suggestions:

  1. Establish IT Governance – this is the prime avenue for engaging the organization on what the IT “black box” (and for us toolkit) is about. It puts a focus on business and risk related problems the organization faces and leverages our technology capabilities to solve them.  A critical factor here is that the IT Governance groups need a budget of their own so the final decision rests with them (as does the accountability!). IT Governance is about “Doing the Right Things”.  Think of this as “efficiency”.
  2. Start an EA Practice – there is no need to buy expensive tools and go into the deep dive of documenting everything. Start simple by creating some guiding principles. Vet them with the IT Governance groups. Then communicate them regularly so the Guiding Principles become part of your organization’s common language. Enterprise architecture is about “Doing Things Right”. Think of this as “effectiveness”.
© 2007-2012 Enterprise Architecture in Higher Education - Leo de Sousa Creative Commons License
Enterprise Architecture in Higher Education by Leo de Sousa is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
Based on a work at leodesousa.ca.
Suffusion theme by Sayontan Sinha

Switch to our mobile site