Enterprise Initiatives

There have been many blogs that argue whether SOA is an IT only initiative or a business initiative. Regardless of who or what is driving SOA, one way to maximize your investment is to align SOA with your company's project portfolio (hopefully you have one).

Let's think about that last statement for a second....

...align SOA with your company's project portfolio.

The value that Project Portfolio Management (PPM) brings to the table is that if done right, PPM ensures that the company focuses its assets (people, products & services, hardware & software, etc.) on initiatives that align with company strategies. Now if you have everyone working on the right projects, the next logical step is to focus your architecture on the projects that bring the greatest value. If the PMO (Project Management Office) does its job and helps the business manage its project portfolio(s), then the architecture team can align with the business to maximize the value of SOA.

I recommend that a company has more then one portfolio. I will use a fictitious company called Acme Toys to demonstrate why.

Acme Toys is a 30 year old toy manufacturer who has a new CEO. The CEO is charged with doubling revenue in the next five years and removing waste from the operational aspects of the business. The IT team has recently implemented SOA and BPM and is starting to reach a modest level of SOA maturity. They have an effective governance model in place that they are constantly refining and have a few high profile projects under their belt. The next step for IT is to figure out where to leverage SOA next.

The CEO gathered his leadership team and put forth a strategy to meet his goals of doubling revenue and improving processes. The CIO and the Head of the PMO proposed creating four separate portfolios to be funded and staffed separately. The picture below illustrates the recommended portfolios.

The growth portfolio is where the company manages the projects that enable the company to double its revenue over the next five years. Within each portfolio there are programs. Programs can be defined as a collection of projects. In other words, a program is a strategy that maps to a goal, while a project is a tactic for delivering the strategy. Here is an example of a Growth Portfolio:
You can see from this example that B2C (Business to Consumer) is a program or strategy. Underneath that program is a list of projects that help deliver the strategy.

The next portfolio is the Optimize Portfolio. In this portfolio Acme Toys focuses its resources on operational efficiencies. Below is an example of what this portfolio might look like.

Acme Toys still needs to keep the lights on so the PMO recommended an Infrastructure Portfolio where IT can drive and manage upgrades, cost reductions, and modernization of its IT services and assets, as well as, deliver compliance or regulatory type projects like SOX or PCI Compliance.
And finally, Acme Toys needs to drive innovation in new products. They have a separate Research and Development team that prototypes various new potential products. This team's charter is to prove out the viability of new product ideas before the company makes huge investments in manufacturing and IT to productionize the product.

That rounds out the four portfolios. Now the IT team has clear direction on where the company is going over the next 12-24 months and can start looking at aligning SOA with the various portfolios. For the sake of this example, let's say that the architect team has enough bandwidth to contribute to two of the four portfolios. It is likely that IT would choose to align with the CEO's goals of growth and optimization. This allows IT to focus its efforts on the programs within those portfolios. The architecture team assigns a group of solutions architects to the Growth Portfolio. They now have a roadmap of projects to start identifying candidate services. With this 12-24 month roadmap of projects provided by the PMO, the architects can then prioritize the candidate services based on business value and potential reuse. By front loading highly reusable candidate services, the architect team can reduce the amount of new development required for future projects. Here is an example.

After analyzing the list of projects for the next 12-24 months, the architect team built a SOA roadmap. They identified two candidate services that would be used in every single project. The first candidate is a product lookup service and the second candidate service pertains to authentication. These two services will be prioritized high and addressed in the first project so the work can be reused in all of the subsequent projects.

The architecture team staffs the Optimize Portfolio with another group of solutions architects. They follow the same process for identifying candidate services for the project roadmap within their portfolio. The enterprise architects provide oversight for both of these portfolios to enforce governance and to take on building or modifying any enterprise wide services that are identified within the projects. The solutions architects work on the application or process specific services.

To wrap up this long post, I hope I have made it clear how Project Portfolio Management can be a great asset to the architecture team in their quest to further entrench SOA into the enterprise. PPM provides a clear vision into corporate strategy which the architecture team can leverage to maximize the value of SOA. I would love to hear your thoughts on PPM and SOA.

1. All of your projects are #1 priority.
2. You have more projects assigned to you then you have people to work on them.
3. Most of your resources are only allocated 50% or less to your project.
4. The users figured out that if they pull a large enough revenue number out of the air, their project will get funded.
5. You can't free up resources to work on the new #1 priority project because your executive sponsor demands you continue to work on the next maintenance release.
6. You have no idea how much the project really costs.
7. Your #1 priority changes week to week.
8. You get half way through the project and the user decides that they don't really need the project.
9. Your project is a year and a half late with no end in sight and nobody wants to cancel it.
10. You have $30K/yr data entry clerks making $80K/yr developers work on non value add maintenance items.

All of these signs are real life examples I have seen in the industry over the last three decades. Without portfolio management, companies waste valuable time and money due to....

• Focusing on the wrong projects
• No accountability for what the business is asking for
• Lack of focus due to out of balance resource allocations
• Having no visibility into the Total Cost of Ownership (TCO) of projects
• Priorities set by the "Bubba System"
• Continuing to throw money at death march projects
• Short term design decisions due to lack of time

Companies should manage their portfolio of projects just like an investor manages his or her portfolio of financial investments. When investing your hard earned cash, many people believe in diversifying. Usually you see a combination of long term, short term, foreign funds, high risk, low risk, and various other types of investments. Most investors have an investment strategy. Younger investors are typically more aggressive because they have more time until retirement. Older investors are typically more conservative because they will have to tap into these funds in a few years.

Businesses should think the same way. They should look at their projects as investments in their company. They should have a mix of strategic, tactical, regulatory, and growth initiatives to name a few. This means that the people requesting the projects should put together business plans that map to corporate goals and show the predicted financial impacts over a five year period.

But you can't stop there. Like all smart investors, once you buy a stock or bond, you typically monitor the performance of that investment. The last thing you need is to be stuck with a few thousand shares of stock that has plummeted from $100 a share to a penny stock. I have seen companies watch projects pass the point of diminishing returns to the point where they pour money month after month into projects that are so late they will never pay out.

Many people view Portfolio Management as another wasteful process initiative. In my experience over the years, many of the issues I have seen in IT stem from an ineffective prioritization process, no visibility into resource allocation and utilization, lack of alignment with corporate goals (if there are any), and lack of visibility into project costs. The end result is a ton of people working very hard, but not working very smart.

In part 1 of this series I asked the question, "Are you running IT like it's your business?" Then I highlighted five barriers for preventing IT leaders from being able to transform their IT shop into a well oiled, cost effective machine?

• Resistance to change
• Lack of resources (time, money, and human capital)
  
• Lack of tools
• Lack of metrics
• Lack of process

In part 5, I will focus on Lack of Process.

Many people in IT think of process as paperwork, overhead, or even a total waste of time. I have seen some processes that fit those descriptions. But in those cases, somebody implemented processes for the sake of having processes instead of implementing a set of processes that help IT deliver quality software and services.

Companies with no processes or ineffective processes have the following issues:

1. Reactive mode, constant firefighting
2. Consistently deliver late and over budget
3. Sweat shop mentality, working hard instead of smart
   
4. Low morale
5. High turnover

All five of these issues are extremely expensive. If you owned your own company and it had these issues would you ignore them? Many IT shops that have these issues look to offshoring as the answer. Can you say doomed? If you can't manage your own internal resources and projects, what makes you think you can manage a group of people in another country? Even if you pick the best offshore resources in the world, the overall success of your projects still rely on your ability to manage them. In other words, it depends on your processes.

There are many types of processes and methodologies that are proven. They range from strict methodologies like CMM and its 5 levels to Agile Methodologies and Extreme Programming (XP). The proper methodology depends on your company culture, your products and services, and your budget. If you are sending a man to the moon, you should use a very strict methodology like CMM. When lives are on the line or millions of dollars are at stake then no short cuts should be taken. If you are implementing infrastructure projects then the PMI methodologies can be a good fit. They provide a good step by step or check list approach that helps you assure that you have not missed a step. If you are delivering applications on the web or providing features for internal or external customers then you probably want speed and that is where Agile and XP come in. With these methodologies, you want to iterate through all phases and deliver in quick intervals. These methodologies focus on getting the right features into the hands of the users quickly and discourage trying to anticipate every user need.

But process isn't just about delivering new software and services. Project prioritization and production support are two critical areas that need to be managed effectively. If either of these two areas are not under control, your chances of success are greatly diminished. Here are the effects of not having a good prioritization process:

1. Over allocation of resources
2. Not working on the most important projects
3. Constant changing of direction, lack of focus
4. Frequently run over budget and delivering late

Here are the effects of not having effective processes to manage production support:

1. Putting out the same fires on a daily business
2. Poor quality applications due to constant patching
3. Poor customer satisfaction
4. Low morale and burn out
5. IT unable to launch strategic initiatives due to high cost and resource constraints
   

So what should you do? Two things. First, implement portfolio management. I wrote an article that could help you get started quickly. Second, look at implementing change management or service management best practices like ITIL or Cobit. By using the best practices for managing change and support, you can reduce your costs, improve your quality, and free up resources to work on high priority projects.

I grew up in a family business and brought the entrepreneurial spirit with me into corporate America. I struggle to accept how some IT leaders do not manage IT like it is their own family business. These leaders are smart people (usually) and I know that they would be taking a different course of action if it was their own family fortune that was on the line. For you IT leaders that live in the world of chaos and firefighting like I have described throughout this series, if you won't drive change for your company, consider doing it for your people. Working hard instead of smart is not what we all envisioned when entered the exciting world of computer science.

This wraps up the 5 part series on running IT like it's your business. I will follow up with a conclusion that discusses how to implement some of these initiatives. Thanks to those of you who have stayed with me for this long series. Please provide some feedback. I would be happy to clarify any points or dive deeper into any topic.

In part 1 of this series I asked the question, "Are you running IT like it's your business?" Then I highlighted five barriers for preventing IT leaders from being able to transform their IT shop into a well oiled, cost effective machine?

• Resistance to change
• Lack of resources (time, money, and human capital)
  
• Lack of tools
• Lack of metrics
• Lack of process

In part 2 I will focus on Lack of Resources.

What are some of the most common phrases you hear when attempting to promote change within your organization? The top one I hear is "I don't have time", followed by "I don't have money", followed by "I need more resources". These are the biggest cop outs in the world. The reason why nobody has time, money, or resources is because they don't put any initiatives in place that allow them to do anything other then put fires out.

At some point you should reach a threshold of pain and realize that there must be a better way. Everybody is working 50-60 hours, all the projects are late, production support continues to increase, and the users are screaming. Everybody is working hard, but nobody is working smart.

If this sounds like your shop, you might want to take a step back and put a plan together to stop the madness. If you owned your own trucking business and you spent most of your time repairing your fleet of trucks you would probably be out of business. So why do so many IT shops spend countless hours every day in repair mode? It's time to make time, time to spend your shareholders' dollars effectively, and time to maximize your precious resources.

Let's start with time. Where are you spending your time? Do you have any metrics that allows you to proactively manage and control your projects or your production support? In many shops, the main cause of all these issues is lack of a sound project prioritization process coupled with a lack of a resource allocation model. If projects get accepted at will, priorities change like the seasons, and you have no data to show that your resources are over allocated, you will become a reactive culture. If you are not practicing Portfolio Management, you should make that a priority (view this article I wrote on Portfolio Management). If you have no visibility into how much time you are spending in production support, what categories of issues you are encountering, and how long it takes to fix issues then you should make change management a priority. If you are meeting with the business to discuss the next wave of new projects and do not have a clear picture of your resource capacity, you need to start practicing human resource planning.

Next is money. Obviously, if you are spending too much time keeping the lights on then you are wasting money. But are you wasting money on infrastructure? Are you still pouring millions of dollars into big name vendors like Microsoft, IBM, Oracle, and HP? Are you paying huge amounts of money for "Gold Support"? You need to start evaluating Open Source alternatives. If you believe in the myths of Open Source, it's time you start doing your homework and read about these 50 Open Source success stories. Oh, and that Gold Support you are paying for each and every product...there are many Open Source Support Providers who can support a variety of open source products at a fraction of the cost. What is better is that these folks earn their stripes supporting customers and are actually extremely interested in helping you resolve your issues. This is their core competency. I wonder how much effort Big Blue would put forth to help a small $100M company resolve its problems. The days of saying, "Nobody every lost their job buying Microsoft and IBM" are long gone. If that is all you are buying you are definitely not seeing the big picture and your CEO might start giving you that look.

Are you still buying rack after rack of servers to support your test, development, staging, and production environments? Have you embraced Virtualization Software like VMWare yet?

And what about human capital? We already talked about spending too much time keeping the lights on and spending too much time maintaining rack after rack of servers. But what about development and testing? Do you have an architecture that allows rapid deployment and reusability? Have you separated your business rules from your applications? If your business rules are embedded in your applications then you are creating additional work to maintain and test your applications thus increasing your chances of creating defects.

Let's say you are a retailer with 1000 stores and you have a business rule for defining what a high volume store is. You have several different systems that use this business rule (billing, inventory, eCommerce site, financials, etc.). Now you want to change the definition of a high volume store. You now have to make that change in each of these systems and implement all of the systems at the same time. This simple change has turned into a project. Wouldn't it be better to go to one place, make the change, test it in one place, and roll? You don't need to practice agile methodologies to be agile. You just need to be smart! My recommendation is invest in your architecture. Create a business rule layer that sits between your applications and your presentation layer. I would go one step further and create a service layer to orchestrate your business rules and allow other applications and/or customers to access your business rules.

Well, I have rambled a lot longer then I usually do so I will pause until part 3 which focuses on Lack of Tools. I will add a conclusion after part 5 that tells you how to prioritize these initiatives and how to get started.