IT Engagement Model

One of the key ingredient for success is clearly defining the roles and responsibilities within IT. There are multiple stake holders in IT with each doing their best to provide the highest level of support to the business. Most of the time this results in people stepping over each other - especially as there generally is a not a clear definition of everyone's task. Most of the project failures are due to the confusion is the definition of the roles between the PMO, Project Manager and the Enterprise Architects, resulting in responsibilities overlap and lack of making decisions.

It is important to do this in the context of the Services Life Cycle and did publish a short presentation on this topic a couple of months back. This presentations is a summary of the SOA Practitioners Guide Part 3: Introduction to Services Life Cycle with the addition of the IT Engagement Model slide (14) shown below.





This is the RACI (Responsible, Accountable, Consulted and Informed) slide listing all the roles and responsiblities of various actors across the services lifecycle. This is pretty generic in nature and could also be applied to non-SOA lifecycles too.

You comments are always welcome and do feel free to drop me line.

- Yogish Pai

Should Enterprise Archtiecture function be outsourced?

Enterprise Architecture is considered strategic by most of the CIO and the interesting question is should the EA function be outsourced ? If the EA team clearly demonstrate value to both the business and IT leadership teams, it does not make sense to consider this. However, not all EA teams are successful and following are some of the trigger points that could get the CIO to start thinking about outsourcing the EA team:

• The EA team establishes standards and primarily acts a police for the enterprise mandating that all business units/projects comply to the standards.
  
• The LOB-IT completely ignores the EA team and makes it's own decision (does not care about the EA team) and most of the time, it is not compliant to the EA standards.
  
• EA team not involved in implementation of any strategic projects by any of the business units.
• Constant churn in the EA team
• No existing Enterprise Architecture team
  

Once the decision is made for outsourcing the EA team, the next obvious question is what should the structure be the outsourced EA team?

Following are some of the key learnings based on my experience:

• Do not out source the entire EA function to a single SI, especially as this would conflict with the dual objectives given to the acting EAs. One given by the customer (develop the most optimum Architecture) and the other by their employers (generate as much services revenue as possible). For organizations where EA teams do not exists, it definitely makes sense for bring in an SI to run this function and later hire people to develop this capability in-house.
• Keep EA management function in-house.
• Have a dedicated EA from one of the major SI as part of the team. This is to bring outside perspective and also a resource who could tap into the SI vast knowledge bases and resources. Based on the budget - I would be tempted to have two EAs - one from each of the major SIs providing services. Competition breeds excellence.
• Have at least one dedicated EA from your major vendors (software, hardware, network) that provide mission critical capability. Negotiate the rates and the resources before signing the major deal and please do not accept the vendor sales commitment to have a dedicated pre-sales resource assigned to the account. Put it into the contract.
• Have the lead technical resource from each of the major initiative be part of the EA team. Example: An SI may be developing a Supply Chain solution and in this case - the lead architect from the SI for this project should be part of the EA team.
• Engage part-time vendor resources on an as needed basis. Example: Once the content management solution is deployed globally, engage the vendor architect to review all major changes.
• Establish a Business Architecture team, ideally from a Management Consulting company or SI that is not providing the technical architect resource to the EA team.
• Establish, communicate and update EA standards, processes, governance, roles, etc.
• Be transparent - i.e. share your budget as well as all vendor proposals with the entire team.
  

The EA team members could all be outsources (on contract) or could be a blend of both employees and contractors. Depending on the situation, it may not be a bad idea to have all EA resources as contractors but make sure the management function is in-house.

Agreed this is contrary to the popular opinion - but something that could be pulled off with the right leadership.

- Yogish

Practitioners Opinion on the Role of a CTO

These days there are a lot of discussions on the role of the Chief Technology Officer (CTO), especially as large and small organizations are planning to leverage Information Technology in a strategic manner. As technology is changing at a very rapid pace, enterprises now have a unique ability to leverage them for providing innovative solution to leapfrog their competition. As the role of the CTO is relatively new, there are various roles CTOs play in an organization resulting in many senior executives expressing confusion about what is and should be the exact role of the CTO.

The objective of this Opinion paper to briefly describe my views on the role of the Chief Technology Officer and is roughly based on the white paper Role of the CTO: Four Models for Success by Tom Berray (Primary Author) and Raj Sampath (Secondary Author). Unlike their white paper in 2002 where they categories the CTO’s into four categories, my opinion is that in this current age CTOs need to have all these attributes.

Please click hear for the Opinion Paper.