Showing posts with label Strategic IT. Show all posts
Showing posts with label Strategic IT. Show all posts

Monday, December 29, 2008

Doing a lot more with a lot less in the current environment

Given the current market conditions all business executives are once again challenging the technology teams to do a lot more with lot less. Following are some of my thoughts around this (nothing new - just going back to the basics).
  • Focus on solving your customers needs - independent of the industry.
  • Do not scale back on innovation. All markets typically are different when they come out of a recession that what they were before one. It is only those who focus on innovation shall come out as winners.
  • Focus on your core business - differ the adjacent market until the market recovers (unless it is related to the innovation)
  • Do not focus on developing new infrastructure (unless absolutely needed). Build out the infrastructure incrementally as new products and offerings are either upgraded and rolled out to customers.
  • Do invest heavily on large packaged applications. As the entire market is going through a shift - it may not be wise to invest in large packaged applications. It will consume a lot of resources (and $$$) without any major differentiation. It may be easier to subscribe for the same applications from a SaaS provider.
  • Do invest in a few strategic initiatives
  • Do not attempt to crawl before you run - "run baby run". The company that runs the fastest to meet the customers demand WILL WIN.

Just some of my final thoughts to close out 2008 and as usual please do feel free to drop me line with your comments and/or feedback.

Wishing everyone a very happy and prosperous new year.

Yogish

Saturday, October 25, 2008

Comparing Current Financial Crisis to SOA - Continued

I agree completely with Yogish's views as posted on "Comparing Current Financial Crisis to SOA" and his advice on treading light and having solid justification prior to undertaking SOA style projects.


A) An upfront investment has to be made in performing the right level of business process analysis and business architecture to pick the right SOA service candidates.


B) One should not attempt embarking on SOA with a highly visible project, as these types of projects operate under unwarranted pressure for delivery and with little patience for "architectural constructs" SOA or otherwise!!


C) Any project that is a high return type process with established KPIs and benchmarks is a good candidate for first time SOA implementations. Here gains are measurable (in the form of cost avoidance, cost reduction etc.) and can be directly tied to SOA-enabling these operational processes.

D) One has to invest in marketing the success of these projects and the services that were responsible for these quantifiable returns delivered by following SOA principles. Advertising the benefits of SOA style services with the benefits rendered by these projects help the business to relate to the abstract constructs such as SOA and so offer a better chance for service adoption. Also, advertising these business services that deliver efficiencies can be shown to offer speed to market gains that can be used for upcoming projects by encouraging reuse.

E) As always one should not assume technology will be the magic bullet. An assessment has to be made to understand if all components of the process/ business capability have to be refactored into services. One has to be open to leveraging legacy assets to reduce risk even if all that can be achieved is establishing a document based interaction or a mediated invocation of the legacy system.

Your feedback is invaluable.
Thank you!!
Surekha -

Monday, October 06, 2008

Organization Skills assessment and Reference Architecture

The other day I was participating in the engineering skills assessment discussion and it dawned on me that mapping the skills to a reference architecture makes is much easier and simpler discussion to have. The reference architecture enabled us to first list the categories and drill into each of them to define the skills as well as leveling required for Architects, Developers, QA and Managers positions.



Key Learning's:
  • Having a reference architecture also helps in organization (engineering) skills assessment
  • The Skills Assessment / Mapping is independent of Governance and Organization. However, Governance drive where these resources belong

Sunday, July 13, 2008

3 Ps of Strategic IT

While working at The Coca-Cola Company we were introduced to the 3Ps at Orientation which were People, Products & Price which translated in something as follows:

"we need the right people to produce the right product to sell at the right price"

I would agree that this is true even today for any enterprise. In my opinion following are the 3Ps key to a Strategic IT.

People:
As always people are the key assets to all organization, especially the ones that make a difference. This is true not only for folks in the leadership positions but also the developers, system administrators, administrative assistants as well as the security guard at the data center. It is important to identify the exception and key people within an enterprise and do whatever it takes (within reasons) to keep them.

Platform:
Even though business keeps asking for solutions, which could be a packaged or custom applications - the platform on which it developed is key. In my experience, even if we adopt a packaged solution for a specific vertical, the customization required to tailor it to the companies specific needs is still very expensive and as for upgrades - forget about it. Might as well do a brand new implementation.

It is heartening to see that all major solution vendors have been focusing on migrating their packaged applications an open standards and tools based platform - which will make it easier for customization as well as future proofing for upgrades.

Process:
When I refer to process - it is not the business process (which is also key) but the process put in place to enable change. Due to fast changing business environment, business will need to transform itself much more rapidly or risk going out of business. This requires IT to help facilitate innovation - a key process that needs to be put in place and made know to the entire organization. And just like any other business process, this innovation/transformation process should also be reviewed on a periodic basis.

Just my thoughts and as always do feel free to drop me line with your comments and/or feedback.

- Yogish Pai

Thursday, July 03, 2008

Best Practice: 5 things that the CIO should focus on

Following are the 5 things that the CIO should focus on in the current environment.

1. Focus on the Demand Side of business
As per my earlier Video Blog on the Changing Role of C-level executives - CIO need to focus on the two sides of the business - the demand and the supply side of busienss. Today most of the CIOs are focusing on the supply side, i.e. helping reduce cost, timely delivery of projects, outsourcing and off-shoring and so on. Yes! COIs do also focus on the Demand side - but not necessarily the primary focus for majority of the CIOs.

The demand side basically means focus on the business demands for new or modified solutions and widely known as Business Agility (read my take on Defining and Measuring Business Agility). CIOs would do well to establish the Business Architecture discipline within the Enterprise Architecture team to help understand and prioritize the demand side of the business.

2. Establish a strong centralized function
Agreed that the LOB-IT is essential to provide adequate services at the business level, there is also a need for a strong centralized function. The two primary centralized functions would be:

Program Management Office: The leadership of the PMO should be close (preferably at the same location) to the CIO and the the others close (at the same location) of the LOB-IT. I have seen multiple examples of remote and distributed PMO organizations which has not worked very well. It not because of individual capability - in my opinion, there needs to a face to face discussions between the PMO, LOB-IT leadership team and LOB - Business Operations teams. The PMO should work in partnership with Enterprise Architecture team to help prioritize and optimize the enterprise (instead of at LOB level).

Enterprise Architecture: This is a key function and once again like the PMO - the EA team, especially the Business Architecture team members need to be close to the business. One more point to note - this is the only team in IT that is paid and expected to look at the long-term picture (not just of the current FY or quarter) as well as influence the optimization of the Enterprise.

Other centralized functions would be IT Operations, Application Development (works for some organizations) and QA/RM teams.

3. Outsourcing
As Ashok pointed out in is blog on SOA and Outsourcing - Despite many of its shortcomings, outsourcing is here to stay. Sometimes, due to resistance from direct reports and other organizations dynamics - CIO may sometimes differ outsourcing (and off-shoring) some of the non-core functions such as Data Center Management, Help Desk and Application Support.

I agree that outsourcing is a difficult decision but a required one. Make sure that you have adequate controls and process in place and one key learning (based on my experience) - the first few months the service may deteriorate or take longer - until the outsources/off-shore team comes up to speed.

4. Enable Innovation
This is a key ingredient for success - not just within IT but also within Business. One of my observations is that some/most IT organizations have a tendency to throw cold water on solutions put together by tech savy business folks. The typical push back from IT are statements like:
  • we were not involved so we cannot support this
  • we have no idea what it does and it's impact in the data center - so we cannot take ownership of this
  • we can redo the entire solutions the right way and it would cost $$$$
  • ....
The CIO needs to step in and make sure that IT organizations do accept and support business solutions - even if they were build by tech savy business folks.

5. People
The key primary assets for any organizations are it's people. The CIO needs to cearly define and communicate the IT principles, identify primary and secondary (that could potentially be outsourced) organizations as well as provide adequate training.

These are the 5 things that the CIO should focus on for establishing a Strategic IT.

As always, your comments are welcome and please feel free drop me a line.

Yogish Pai

Tuesday, June 24, 2008

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

Monday, May 19, 2008

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

Friday, May 16, 2008

Enabling Strategic IT through Services-Oriented Architecture

Lately there have been a flood of negative comments about Services-Oriented Architecture, especially about providing business value. In this blog I have attempted to provide a simple example on how SOA, if done right, could provide substantial value to the business for an enterprise.

Read more about this at my IT toolbox blog here.

Thursday, January 17, 2008

Created Google Groups to continue the discussions further

As we now a number of subscribers for our blog we have gone ahead and created a Google Group to help facilitate discussion within the subscribers. Please do join us to have a more detailed discussion on any of these topics by clicking on Visit this Group. Plus have interesting conversation with your peers in the industry.

- Yogish

Tuesday, December 04, 2007

Blueprinting Information Architecture and BPM

Following my blog on Key Learning: Blueprinting Information Architecture is key to successful adoption of SOA one of the feedback was Don't we need to define the detailed business process to identify potential service candidates?

My response to that is No and explained it in this edition of the Strategic IT Update. Please click here for all the Strategic IT Update presentation and transcripts.

Reference: Customer Data Integration: BEA-IT Case Study (my presentation at CDI Summit in 2006)

Thursday, November 29, 2007

Strategic IT Update: Changing Role of C-Level Executives

The business environment is becoming more complex, unpredictable and constantly changing. In the near future IT will no longer be the way it is today. Business and Technology integration will be a necessity for business to stay competitive. To achieve this, the CFOs role is expected to become increasing important as described in this video.

Following is the first Strategic IT Update.



As this is my first production, I have intentionally kept it short so as to work out the release logistics.

Yogish Pai

Key Learnings - Using EDA to implement the core SOA principle of "loose-coupling"!!!

A lot has been said about how SOA and EDA are unique "architecture styles". It seems like only one or the other architectural prin...