I have been thinking a lot about re-engineering the service delivery model for the application services team that I lead. I have been guiding my team to think about:

“We deliver the platform and work with the business to provide services”.

Our applications team is made up of subgroups aligned by major application services.  Here are the major applications:

• Business Intelligence
• Collaboration Tools
• Document Management
• Email and Calendaring
• ERP (Student, Finance, HR, Doc Mgmt)
• Identity Management
• Learning Management Applications
• Microsoft Applications
• Oracle Database
• Portal (for students and employees)
• SQL Server Database

Currently, there are 3 teams in place in our Business Application Services group. Here are the roles in each team:

Support Team

• Oracle DBA
• Document Management
• Business Intelligence
• Project Management
• Business Analysis
• Identity Management

Email and Collaboration Team

• Email
• Calendaring
• Instant Messaging
• Collaboration Platforms
• SQL Server DBA
• Microsoft Applications
• Enterprise Portal

Developer Team

• Oracle Developers
• Lotus Domino Developers
• Microsoft Developers
• Java/Web Services Developers

I am interested in hearing from any of you that lead groups with similar responsibilities.  Do you have a suggested structure for me to consider?  Do you split your team based on roles (technology domains)  or by application (vendor) platforms? Do you split operational work from project delivery?  Does your governance structure influence your teams organization?

Any suggestions are very welcome and I hope to learn from some of your experiences.  Thanks in advance.

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.  Read more...

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:  Read more...

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”.