Enterprise Initiatives

I have spent a lot of time recently questioning the leadership of IT organizations who become a cost center due to a "keeping the lights on" mentality and have asked the question Are we Sleeping at the Wheel?. The other day I stumbled across a great article (thanks to some of my pals from Twitter land) that really hits the nail on the head. This is a must read article that brings to light what I think is the main reason why many IT leaders are missing the boat on emerging technology trends. The article is written by Steve Andriole is called Managing IT: Changing Our Minds (About Everything) and discusses how IT leaders who have been around a while have to let go of solutions of the past and totally change the way they think. Here are a few excerpts...

Here’s the deal. The world has changed – forever. First, hierarchical management structures will weaken as we continue to globally decentralize our business units. We have to change the way we think about control, standardization and the overall governance we bring to technology acquisition, deployment and support.

Here is his thoughts on Open Source which I have been championing for quite some time...

Open source is here to stay. Even the established vendors have “embraced” open standards. They have no choice. Do you?

And what about cloud computing?

We need to change how we think about cloud computing from an incremental shift in technology offerings to a whole new way of acquiring, delivering and supporting digital technology

Here is my favorite...

Debating endlessly about whether or not open software, cloud computing or SaaS have any merit is a waste of time – and most likely a diversionary tactic designed to slow – if not outright kill – the pace of change.

Please take the time to read the entire article. I think the message is an important one. If you are an IT leader who is missing the boat, you need to reevaluate your positions on the emerging technologies and solutions. If you don't you are damning your organization to more years of fire fighting and being a bottleneck to the progress of the business. Don't miss the boat!

As I look out into the future of IT over the next 5 to 10 years, I see a huge shift in how IT shops will need to operate in order to help their companies survive. We are already well aware of the pressing needs for IT to provide agility and flexibility for its business partners due to the speed at which the business landscape is changing. The forces of globalization, economic pressures, and advancements in technology are creating as much change in an 18 month period than we used to experience in a decade. In order for companies to survive and thrive, they need to adapt. As Charles Darwin once said,

“It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change.”

I wrote a post last year called How did we become a Dilbert cartoon which discussed my theory on how IT has become so out of touch and bogged down with trivial issues. I see Dilbert every day whether it is at the places I have worked, the case studies that I research, the discussions I have with peers at conferences, or from the forums and user groups I participate in. Somewhere along the line, many IT professionals in the US have forgotten what IT's purpose is and take their IT profession for granted. These people put themselves and their favorite technologies first and their business and shareholders second. How many important initiatives have you seen stalled because certain individuals refused to change or learn something new? Look how many companies are struggling implementing transformational initiatives like SOA, ITIL, business process reengineering. All of these types of initiatives can make a huge impact to the bottom line. But how many of these have stalled because people fought these initiatives with all of their might? The basic problem is that transformational initiatives requires transformational leadership! How many leaders within IT do you know who excel in the three critical areas of transformational leadership required to deliver technological solutions: Business Acumen, People & Organizational Skills, and Technology skills?

From Misc IT

Looking down the road, I see certain technologies maturing and becoming critical to helping businesses staying competitive. These technologies are:

• Infrastructure as a Service (IaaS)
• Platform as a Service (PaaS)
• Social Networking/Software within the enterprises
• BPM, SOA, and Event Processing working in harmony
  

I am amazed at the number of pundits that exist for all of these technologies, especially cloud computing. Many people are strongly against these advancing technologies at the expense of their own careers (they just don't realize that they are making themselves the equivalent of Y2K programmers yet). Sure, cloud computing has its challenges with data security, privacy, and in some cases reliability, but it is in its infancy state. Instead of focusing on what the limitations are, we should focus on the huge strategic and financial opportunities that it creates. Let me quote Darwin again.

“Ignorance more frequently begets confidence than does knowledge: it is those who know little, and not those who know much, who so positively assert that this or that problem will never be solved by science.”

I still remember the naysayers doubting PCs and distributed computing and declaring that nothing could beat the mainframe. Do you here the negatively by some about social networking and social software? Doesn't it sound like the negativity we heard when people were trying to bring the Internet into corporations?

Why do we get in our own way of progress? Why are we living in Scott Adam's world of Dilbert? Why do system administrators fight cloud computing? Is it fear of job elimination? Loss of control? Not wanting to learn something new after 20 years? Why do IT professionals revolt against SOA? Does it require them to actually architect something rather than drag-n-drop some code in their favorite Microsoft IDE? Does it force them to collaborate with other people including business people and take them out of their comfort zone? Is it hard work? I don't know what the answer is but I do know that with out transformational leadership, the resistance can put up huge barriers and can kill initiatives that can give a company an edge over its competition.

What about outsourcing? Do you really want to get IT professionals fired up? Just the mention of the word brings anger and negativity to many. But why? Maybe we all need a lesson in economics or should simply read the book The World is Flat. While we in the US are sitting here complaining about change, countries like China, India, Taiwan, Ireland, and many others are graduating engineers by the thousands. These folks are more than willing to work on any task that they have the privilege to be given. And there lies the problem. To these people, work is a privilege, a way to have a better, more prosperous life. In the US, many people see their job as something that is owed to them. How many people in your shop are actively working on improving their skills? Just the fact that you are reading this post puts you many steps ahead of most. Many people that I have worked with in my 23 years do not invest their own time and energy required to continue to learn and adapt to the world around them, both from the technology and the economic standpoint. I am fine with the fact that many people value their personal time way more than some of us do, but if you don't invest the time you do not have the right to impede in the advancement of the organization!

Getting back to the emerging technologies that I mentioned above. To be successful implementing the transformational change to embrace these technologies, IT shops need the following foundation:

1. Strong leadership with the ability to promote and manage change
2. A well run and planned Enterprise Architecture
3. Solid working relationships and trust with the business partners
4. Discipline
5. Fiscal awareness
6. Numerous Strategic Partners
   

Strong Leadership
The leader(s) must be visionary, strategic, emotionally intelligent, and must be able to execute. I have seen leaders who have great ideas and are pretty smart, but they fall down when it comes to execution. Nine times out of ten, the failure can be contributed to people not the technology. In other words, resistance to change prevails and the company reverts back to the status quo leaving IT with the reputation of a cost center. The following presentation speaks to how to anticipate and plan for change up front to reduce the odds of failure.




Enterprise Architecture
To enable a flexible and agile enterprise, it all starts with an architecture that maps to the overall business strategy. No longer can we afford to build software in silos and continue to pay huge sums of money to keep the lights on. In order to be efficient with our ever shrinking budgets, we must have an IT strategy that is supported with an architecture geared towards maximizing our resources (both human resources and technology resources). The more standard and consistent the architecture is, the easier a company can move to the clouds, alter business processes in days instead of months, change business rules on the fly, adapt to mergers and acquisitions, and connect to partners, suppliers, and customers. Remember this, your biggest threat tomorrow might be a company that does not exist today! Why, because a startup does not have legacy to deal with and will most likely embrace these new technologies from the start and race right by you to the finish line. Companies must change or die. The following presentation speaks to the value of EA.


Relationships and Trust
In order to accomplish transformational initiatives, IT must forge great working relationships with its business partners, both internally and externally. Without the trust, funding and executive level support will be extremely hard to come buy. To earn that trust, IT must understand the business and put forth solutions that are beneficial to the business first and IT second. The following presentation shows an example of how SOA was explained to the business in tangible business terms (increase sales, customer satisfaction, etc.) instead of technology terms (reuse, ESBs, services, etc.).


Discipline
This is critical. We can no longer fly by the seat of the pants anymore. It costs the company too much in maintenance and hinders agility. That is not to say that we should all embrace heavy methodologies like CMM. There needs to be the right balance between process and agility. And for those IT professionals who will fight process to their death beds, there are millions of knowledge workers in foreign countries hungry to do your job for you. Today's resistance is tomorrow's unemployment.

Fiscal Awareness
Being fiscally aware is a key contributing factor to allowing IT professionals to see the "big picture". After all, the main purpose of most companies is to make money, or in government, to make the best use of tax payer dollars. It's all about money! So why are so many IT professionals so clueless about the financial impacts of the work they do and the decisions they make? How many times have you sat in meetings with armies of people for an hour or two and nothing gets accomplished? How does that contribute to the bottom line. When technologists argue about .Net vs. Java, or IBM vs. Dell for months on end while projects get delayed, why doesn't anybody seem to care? When IT professionals make technology decisions primarily for the sake of technology, they often make a choice that is not fiscally responsible. When making these decisions we must think about more than how we will use the products within IT. There are many factors that need to be consider. We should look at the feasibility not just from a technical standpoint, but also from an economic, operational, and political standpoint as well.

Strategic Partners
And finally, there is so much change and so much to learn, it would be suicide to think that we could deliver anything transformational in a reasonable amount of time without the help of partners. The business can't wait for IT to train an entire staff to a high level of competence on these emerging technologies. They also can't wait for us to stumble and learn from failing in production. Instead we will need strategic partners in many areas to help build the agile enterprises of tomorrow. These partners may be used for the following reasons:

1. Business Process Outsourcing (BPO) - (example: Payroll, HR, web site hosting, etc.)
2. Acquire new skills (SOA implementers, BPM experts, Cloud specialists, etc.)
3. Strategic partners (Organizational Change Management expert, EA help, etc.)
4. Technology outsourcing (IaaS, PaaS, SaaS, etc.)
5. Project based outsourcing

Outsourcing does not mean the same as offshoring and outsourcing does not always relate to development. When cost is an overriding factor offshoring is a no-brainer. Of course without EA and discipline, outsourcing may cost more than expected. There is simply too much to do and so little time to do it. Find the right partners and hold them and yourself accountable for transferring the knowledge to members of your staff.

Summary
I apologize for the length of this post (if you made it this far). I am very concerned for the future of my IT colleagues in the US and had to do a "core dump" on this post. After many years of prosperity, many IT professionals in the US have become intellectually lazy and blind to the opportunities and challenges that this new economy has created. The combination of our financial crisis coupled with the forces of globalization and technological advances will create radical changes over the next decade. Many professionals are too wrapped up in reality TV to realize that the world is catching up and is ready to pass us by. Those who understand that can embrace the new opportunities that these conditions will create. The others will be the equivalent of the Y2K programmers who did not embrace the post 2000 innovations. I'll leave you with another great quote from Darwin...

“In the long history of humankind (and animal kind, too) those who learned to collaborate and improvise most effectively have prevailed"

I just read Dave Linthicum's post on SOA World titled Should you Fire your CIO? This is a continuation of a discussion that has been brewing in the blogsphere for the past few months that started after the Burton Group commented that a new CIO was often a key ingredient for some successful SOA implementations.

To successfully implement enterprise wide SOA initiatives, strong leadership is required at the top of IT. The person must have integrity, creditability, technical and business know how, and must be able to lead the organization through the resulting shifts in cultural values. The problem is, as Dave points out in his article....

....in many organizations the role of CIO has resolved itself as the person who keeps things running, not the agent of change.

I call this the old "Keeping the Lights on Mentality". When IT stops being an enabler and simply acts as a cost center or a "necessary evil", then entertaining new projects that leverage one of Gartner Top 10 strategic technologies is unrealistic and doomed for failure or hardship at a minimum. Why? Because this mentality is reactive and sometimes even defensive. This mentality also does not encourage investing in the future whether that is in training employees, establishing and investing in architecture, or addressing problems with long term solutions. Instead, people are rewarded for quick fix fire fighting heroics and at the end of the day it is the user community that suffers. The users get band-aids on top of already outdated systems and are often forced to work in ways in which the technology and systems dictate, instead of the other way around.

It gets worse for the employees in an IT department in charge of "keeping the lights on". Their resumes become stale as their skills are not updated to reflect the newer technologies that innovative companies seek. The reactive nature of the culture can squash innovation and people who have valid solutions may not bring them forward because it would require more than a quick fix. In the end these types of shops become like an assembly line in nature where people clock in, work their shift, and clock out. This is not what must of us envisioned when we enthusiastically enrolled in IT related curriculums in college back in the day.

The key business driver in a "keeping the lights on" shop is minimizing costs (usually over anything else). Which makes me wonder why more shops in this mode do not go down the outsource IT path. If lower cost is so important and large innovative initiatives are typically out of the question, why not radically lower the cost by outsourcing IT? I am not recommending that IT shops do this, instead I recommend that IT shops become good business partners and enablers of business success. But if I was a CEO or CFO and my IT's sole purpose was to be a cost center to keep the lights on, I would try to drastically reduce that cost. After all, keeping the lights on is not a core competency of most businesses. It is a necessary evil. Having hordes of full time staffers and paying for their benefits, stock options, and bonuses just to keep the lights on is not smart business. I know my view here will not be popular with most IT folks. I am not down playing anybody's abilities here. All I am saying is that if we don't need our staffs to be innovative, proactive, and be advocates of our business partners and instead just want to the staff to think short term, there is a much cheaper model out there.

So to answer Dave's question, if the business wants IT to help the business achieve its mission by being proactive and innovative and IT is simply keeping the lights on, the answer to his question might be yes. If the business simply needs a low cost IT cost center, the answer may be to evaluate the outsourcing model. Keeping the lights on as a core IT function and doing it at a high cost is just not good business. That's my 2 cents.

Disclaimer: In no way is this article referring to or targeting any organization or individual that I have been associated with in my career. This is a generalized view that combines my own experiences with the experiences of thousands of other IT professionals that I have talked to, read about, or researched throughout my 20+ years in IT.

For those of you who have been reading my blog for the last two years, you might know that after 13 years at my previous job I left the company this summer to pursue multiple opportunities that were available to me. I have been doing some consulting and freelance writing in the mean time but have finally found my new gig. I will be the CTO/Chief Architect for a startup (more details forthcoming in the future) and will have the opportunity to work on some of the newer technology initiatives. So here are some of the future blog topics that I will start covering in 2009 once I get rolling:

1. SOA - can't seem to let it go! As I wrote in a post at CIO.com, I believe SOA is not just for legacy systems and can be the foundation that startups can leverage as a competitive advantage (see the reasons why)
2. Cloud Computing - Startups typically have low budgets and leveraging platform (PaaS) and/or Infrastructure as a Service (IaaS) can be a great way to both minimize costs and reduce time to market. As I go through the requirements analysis, risk analysis, vendor analysis, proof of concepts, prototypes, and deal with issues such as stability and privacy, I will share my lessons learned here.
3. Open Source - We will likely leverage many open source solutions and I will discuss those experiences and decision points here.
4. Social Software - The company is based in the North East and I live in Florida. It is highly possible that the team I build will be dispersed all over the country and possibly even the world. There will be great lessons learned discussions as well as evaluations of tools to help enable working remotely (virtual whiteboards, live meetings, SaaS solutions for defect tracking, etc.).
5. Agile - One of our goals is to deliver quickly and at low cost. This involves a lot of the above mentioned topics and will also lead us into the world of Agile Development. I will discuss our challenges and lessons learned in this area as well.
6. C-Level IT topics - In my new role I will be working side by side with other C-Level people within the company as well as with C-Level people of partner and customer companies. I will have to hit the road and sell and/or promote our products/services and will try to shed some light on some of the interesting topics I come across.
7. Misc - Other topics that might be worthy of discussing (examples: impacts of financial crisis, VC funding, selling technology to business people and customers, etc.)

In addition, I still do some freelance writing and blogging from time to time. I have a series of discussions coming up on enterprise mashups and will blog about it in the next week or two. I am attending and speaking at the EDM Summit in Orlando next week and will definitely be sharing my presentation on Business Intelligence as a Service as well as covering topics like business rules management, data warehousing, IT governance, and others. I also have two books from Packt Publishing to review:

• SOA Governance by Todd Biske
• SOA Cookbook by Michael Havey

Once I finish reading these I will post a review on my blog. I am half way through Todd's book so far and really like it.

And finally, I am open to covering any topic that any of my readers would like me to discuss whether it is on this blog, over the phone, or in person. Whenever I travel I send a Tweet on Twitter to let people know where I can be found. I will be in Pittsburgh from Saturday 10/25 through Monday 10/27 if anybody lives there and would like to meet. Don't bug me from 4:15-7:15pm on Sunday because I'll be at Heinz Field pulling for my Giants against a tough Steeler team. The rest of next week I am at the EDM Summit in Orlando.

I look forward to sharing these topics with you all. Over the next two months my focus will be on the business plan and creating a team. We officially launch the company in the December-January time frame. At that point expect to see more discussions on the topics I mentioned above.

I frequently discuss SOA with potential clients, fellow architects, and business partners. Each audience requires a discussion that is tailored to the appropriate level of technical and business expertise. Today I had to present to a CEO and a few of his top staffers about what it takes to launch into a SOA initiative. So I put together a presentation similar to the one below and felt like sharing it with all of you.

Before you look at it let me put the discussion into context. The target audience is hi level management, business and IT, who are already bought into SOA and are trying to understand what is involved before they launch into a full blown SOA initiative. This is not a presentation for architects, rather it is to inform C-Level stakeholders what is required from a business, technology, and culture standpoint.

I also had to sell to them that I know what I am talking about, hence the first few slides about my background. One last note: Some of the slides are mostly visual and only get the point across when backed up with talking points.

I hope this adds value to some of you. Enjoy!

The last few years have brought many great advancements in technology and the upcoming years promise to bring more. As companies push to drive the costs of IT down while increasing productivity and output, many large enterprise initiatives have become high priorities. The chart below shows IT's top 10 Management priorities for 2008 (source: CIO Insight):

When you look at this list it is obvious that today's IT leaders need to be experts in more than just technology. They need to understand the business and they need to have good people skills. I created the following diagram which I call the leadership triangle. I feel strongly that IT leaders need to excel in all three areas: Business, People, and Technology.




From the business perspective, not only do IT leaders need to know how the business's products and services function, they also need to be able to speak in business terms. This requires MBA type skills in the area of Finance, Economics, and Accounting. When you produce your business case for initiating a large new technology project like SOA, Green initiatives, or ITIL you must be able to describe business benefits in terms of NPV (net present value), IRR (internal rate of return), and payback periods. When dealing with infrastructure projects like disk consolidation, virtualization, and others you should understand the different rules of depreciation, lease options, contract and vendor management. The list goes on.

From the people perspective, the IT leader must be a coach/mentor, great communicator and presenter, skilled in leading through change (organizational change management), a negotiator, a sales person, and a visionary.

From a technology perspective, IT leaders must have at least a high level knowledge of a variety of areas including architecture, security, infrastructure, regulatory/compliance, data, quality assurance, operations, etc.

It is rare to find one person who excels in these three areas. If you find one, good luck keeping them around for a long time because they are highly sought out. Some companies can accomplish this by assembling a strong leadership team that works closely together towards common goals. This requires the leader of this group to be exceptional from the people perspective.

IT must embrace itself for constant change.
The next chart shows IT's top ten technologies for 2008 (Source: CIO Insight):

Some of the key IT initiatives that could come from this list are SOA, BPM, Business Intelligence, Master Data Management (MDM), Virtualization, SaaS, ITIL, Portfolio Management, Social Computing, and many others. Each one of these initiatives requires people to change the way they have traditionally worked. Some roles and skills may go away and new ones may be created. Many of these initiatives require very specialized skills and demand more collaboration across different areas of expertise, including business SMEs (subject matter experts).

But the technology is the "easy" part. Getting the business sponsors to own and help drive the initiatives and leading people through change is where IT has a huge skills shortage. Many people in IT don't even acknowledge that these two things are important. I can't count how many articles I have read that claims SOA is a failure and is nothing more then hype. The same is said for enterprise architecture (EA) where recently EA has been called a joke. The joke is that companies try these large enterprise initiatives without relevant business drivers and without having an organizational change management (OCM) plan. Many think by simply having smart technicians, they can get any IT project done.

The future will drive even more change.
Over the next few years, cloud computing will become a key driver for reducing complexity, reducing costs, and improving agility. I recently made a short vlog (video blog) on this topic. Software as a Service (SaaS) and Platform as a Service (PaaS) will cause a major shift in the way we think and work. There will be all kinds of resistance from the infrastructure and security staffers. Moving to a platform in the cloud is a threat to the current roles and responsibilities for these folks. Over time (5-10 years), PaaS will become mainstream and IT shops will likely become smaller and will definitely have a different technical makeup then it has today. People will have to retool and stay current with trends. Software will become a true engineering exercise that requires knowledge of distributed systems, security, data management, and networking. Drag-n-drop n-tier developers will become the Cobol programmers of our next decade. Globalization and social software will radically change the team structures. Project teams will be scattered across the globe. Rising oil prices will lead to more virtual offices. Ten years from now we will look back and laugh at the notion of cramming hundreds of people into cubes. Companies will be able to hire staff from around the globe and won't be restricted to local markets. Users will have the power to assemble their own applications by leveraging mashups and software in the cloud. How will we manage the future?

IT Leaders need to change with the times
So what does this all mean? When you add up all of the things I just mentioned, the role of management has become far more demanding. If your managers are struggling today, how will they survive tomorrow? Just think of the cultural and ethical ramifications of managing a remote team of workers from around the world. IT leadership will be even more demanding then it already is and we already have a shortage of leaders who excel in all three areas of the leadership triangle. So how will we solve this dilemma? Currently, many IT shops just "stay the course" and do not adopt any of these large enterprise initiatives. In the future as cost reduction becomes a matter of survival, many of these initiatives won't be optional.

Unfortunately, I don't know the answer to my own question. There is already a skills shortage in IT across the board. There isn't a shortage of people applying for management and leadership positions, but there sure is a shortage of people who are qualified! Where will the next generation of leaders come from? How many companies will recognize the importance of the leadership triangle? How many more IT projects will fail before somebody does something about this dilemma?

What do you think needs to be done? How will we overcome the Leadership shortage?

First it was WOA vs. SOA, now it's Mashups vs. SOA. When will people start focusing on business problems and stop having religious wars about which technology is best? All of the above mentioned technologies are great tools for your IT toolbox. They should be used where they make sense. SOA is an architectural approach. Mashups and WOA are technologies that work well with SOA. Why can't we all get along?

One of the items on our SOA roadmap is extending our architecture to include mashups. We envision leveraging popular mashups like Google maps but we also hope that our customers can extend our products and services with their own mashups. Take a look at all of the mashups that are available for Salesforce.com.

I've said it before and I'll keep on saying it until somebody proves me wrong. The problem with these emerging technologies is not the technologies themselves, it is the people. Only people can take great concepts like SOA and Mashups and create a bunch of unnecessary noise that scares the masses away. Instead of arguing about semantics, people should try to better understand these concepts and figure out how they can apply them to solve real business problems. At the end of the day, the business doesn't care what technologies you use. They just want their tools delivered faster, easier to use, and at their finger tips wherever they are.

Lately I have been getting a ton of calls from recruiters who are looking for some really smart people for various technology jobs. I don't know where they are getting my name from but they all know that I have a very solid network of talented people. Most of the jobs are in the North East or the West Coast. I am in Florida and have no plans to leave the Sunshine State any time soon. The gentleman who called me today said, "I was told that you are the guy to call because you know a lot of people in IT". That got me thinking. Between my connections on ITToolbox, LinkedIn, Plaxo, Facebook, and Twitter, I have about 500 IT people in my network with various talents. Why not share these opportunities with my friends and colleagues? I sent out a couple Tweets on Twitter but I want to try out this blog for a new way to share job leads with my network.

So if you are a recruiter or employer and are looking for some good people, shoot me an email (mkavis@yahoo.com) or a Tweet (madgreek65) and I will start a weekly post on job openings. This is totally free for both the talent seekers and the job seekers.

Here is my motivation. I have been contacted on some very attractive, high paying positions in states that I cannot move to. I would like to give those in my network an opportunity to inquire about these jobs that are typically not posted anywhere. Also, I would love to build a trusted network of recruiters and employers. You never know when they might return a favor for me or for someone I know.

So here is an attractive job that I sent out on Twitter today:

Recruiter called and is looking for IT Director for small loyalty marketing co. in Rochester, NY. Call Alan 732-463-1414.

I will send job notifications like this out on Twitter when I get them and will have a weekly post that summarizes all of the jobs I hear about during the week (if I get any). Currently I get 2-3 calls/emails a week on average. If you know any recruiters, forward them this post. If you are looking for a certain job opportunity, let me know so the next time they call about a particular job I can send them your way.

If I get enough people participating, I'll create a new blog dedicated to sharing job leads to connect recruiters with talented IT people. If I don't, no big loss. Let's give this a try. It is so hard to get your foot in the door these days. It is all about who you know and who can get your resume passed the paper shredder in HR. All I ask in return is that you check out my blog every now and then!

Whether you are implementing an Enterprise Architecture, SOA, or in my case, both, dealing with change is by far the hardest part of the project. I just happen to be taking a graduate level leadership class right now (timing is everything!) and we are studying different change theories. The one that I like the most is Kotter's 8 steps for transformation.

1. Establish a Sense of Urgency
2. Form a Powerful Guiding Coalition
3. Create a Vision
4. Communicate the Vision
5. Empower Others to Act on the Vision
6. Plan for and Create Short-Term Wins
7. Consolidate Improvements and Produce Still More Change
8. Institutionalize New Approaches

If you take these steps and apply it to EA or SOA, you can get a list of steps like this:

1. Build strong business case
   
2. Secure executive sponsor and top level buy in
   
3. Create a Road Map
   
4. Communicate the Road Map
   
5. Empower Others to Act on the Road Map
   
6. Start small, deliver early and often (agile)
   
7. Expand, leverage reuse
   
8. Govern

Most articles that I have read discuss two critical elements: the technology and governance. Not enough people are talking about change management. I would like to invite my fellow EA bloggers and industry experts to write a blog post (or two) on how to effectively promote change throughout the organization.

For those of you who have been reading my blog, you know that my company has been working on various projects that leverage BPM and SOA technologies. One of the biggest challenges we have is dealing with culture change and providing the right level of communication to people at all levels. Next week, we plan on implementing a few Enterprise 2.0 technologies to address those challenges.

Enterprise 2.0 is a fancy term that represents a host of web based collaboration tools like blogs, wikis, social networking platforms, RSS readers, bookmarking, tagging, and many others. Dion Hinchcliffe has one of the best blogs that explain Enterprise 2.0 (also called Web 2.0 in Business). His article called Social Media Goes Mainstream does an fantastic job of explaining Enterprise 2.0 and its benefits.



Back to my scenario. On our corporate portal, we are launching an enterprise architecture community which will link to the wiki and our blogs. Members of our architecture team will blog about various topics to share lessons learned, tips and tricks, and various research information as we learn more about the technologies we use. Our project manager will blog about the project, our testing architect will discuss the ins and outs of testing SOA, our configuration management guy will cover his area of expertise, and I will blog about the EA team's vision and strategic direction. All of our governance information will be accessible via our wiki. We are leveraging Mediawiki, the same open source wiki tool that runs Wikipedia. For the blogging software we are using Wordpress, another open source tool. Our next step is to implement a RSS reader so people can subscribe to content that is relevant to them.



Driving traffic to this new community on the portal can be challenging. Our plan is to have our CIO send a biweekly communication to all of IT. He will distribute an email with a URL to his blog which should bring most people to the site. In his blogroll will be links to the EA team's blogs and the enterprise wiki. Our hope is that in addition to keeping people informed about projects and technology, people will start to collaborate on the site. Once the collaboration starts, fresh new ideas should emerge from the staff and knowledge sharing and collective intelligence will prevail.

If this new EA community is successful, we can take it to the next level and start experimenting with tagging and social bookmarking. This will allow people to tag and rank information that is relevant to them which in turn makes popular content easier to find. One of the challenges that many companies, including ours, have with their portal is that it is difficult to find documents. Tagging and ranking solves this problem.

So next week we unleash some of these Enterprise 2.0 technologies to the masses. I expect adoption to be slow since many people are probably not familiar with these tools. But the biweekly CIO communication should be the "killer app" that drives the traffic to the site. Hopefully these tools will improve communications. We will still use all of the other communication mechanisms as well, but the blogs will allow for frequent, short communications that can reach large audiences in a short amount of time.

I will share the lessons learned on this experiment as we encounter them.

Eric Roch wrote a great piece today called The Difference between SOA Theory and Reality. I started to comment on it but my comments turned into this post. Eric's key point is that there is no one right way to implement SOA.

The reality of SOA is that every company is unique with widely different systems (as-is architecture) and culture .... The approach to governance and organizational structures will depend on the culture and capabilities of the organization.

This is true for all technologies not just SOA. I have read countless articles about the best approaches to delivering SOA, Enterprise Architecture (EA), ERP solutions, Business Process Management (BPM) and many others. Bloggers get into religious wars about how their approach is the only correct approach. These bloggers might generate a lot of traffic but they are doing the community a disservice. As Eric says, every company is different. In some companies, IT budgets are handed to them at the beginning of the year. These companies have to make due with the dollars they have and running a top-down SOA project is virtually impossible. In companies like mine, the business is funding the SOA and BPM initiative. We have specific projects that justify the expense of the infrastructure and capital investments for SOA. Once again, Top-down does not work in this scenario. This requires a bottom-up approach since the business is expecting new functionality every couple of months. In other companies, IT can be more strategic and budget for a multi-year SOA implementation. In this scenario, a top-down approach can be a reality.

Whether it is EA, SOA, ERP or others, it really comes down to these variables:

• Business driver
• Level of executive support
• Culture
  
• Time
• Money
• Talent

The combination of these variables should lead you to the solution that will work in your world. The thing that people need to understand is that there is a difference between what is the best way of implementing technology from theory and text books versus what makes financial and strategic sense from a business standpoint. At the end of the day, it's not about the technology, it's all about the business.

I wrote a piece called Why are you still generating reports that spawned a few other posts from fellow bloggers James Taylor, Todd Biske, and Robert McIIree. Robert had an interesting point of view which I would like to discuss. In his post he stated:

Excel and similar tools are used for two reasons: first, because it is very familiar to most users and "good enough" to generate reports and analytic output; and second, such use is quick and effective without running through the IT gauntlet to enlarge the effort by "gathering requirements," making it a full-blown project, and waiting a long time for "results."

I agree that Excel is user friendly and a favorite of most business users. Excel is an acceptable tool to manipulate data but should not be used as a system of record. I have seen too many occurrences of key financial data/reports residing on someone's C: drive with no way of validating the integrity of the data. I have also seen many business users create their own "systems" by pulling data out of various databases and building critical reports that are most likely inaccurate. Why are they inaccurate? First, most users don't understand the concepts of data integrity, don't have access to data dictionaries, and don't understand the physical implementation of the data which means they have limited means of validating what they have created is accurate. Second, since IT usually has no idea that these systems exist or how they are updated, changes to the source data are made without the knowledge of the end users' home grown systems. So I say Excel is a great tool for dicing and slicing data but the business community should not be driving the business off of home grown Excel systems.

Further down in the article Robert states:

Instead of asking "What problem are you trying to solve?" we should be stating "Here's what we have available, what is missing or needs to be altered for your needs, and will this work in other parts of the business?" The former question implies that IT knows more about the business and its specific issues than the business does.

Which it doesn't, and never did.

I understand Roberts point but this is where I ask the question, "Are you customer centric or a customer servant?" If you are a mere servant for the business, when they ask for stuff you simply build it the way they want. At the end of the day, you are letting the users design systems. If you are customer centric, your goal is to provide the business with accurate tools while at the same time ensuring that the business processes being requested are value added. One of the main reasons why BPM is so hot these days is that we have been servants to the business for years. The business knows what they need to do their jobs, IT should know how to provide solutions to meet those needs. My company just reevaluated its business processes in a certain area of the business and found that over 50% of the processes were non-value add processes, also known as waste. Why is this? For years the users asked for reports and we created them. The users knew what they needed but they did not ask us to build the right solution, nor should they. Here is an example:

We were asked to create a "data quality check" report to ensure that a certain attribute in a legacy order entry system matched the appropriate value of an attribute in a legacy financial system. The real problem was that the order entry system needed additional quality checks in the user interface to prevent erroneous data from getting into the database. So if I did not ask the question, "What problem are you trying to solve?", we create a new report accompanied by a new non-value add business process which requires manual labor to validate and to correct and does not guarantee that the problem will get fixed. If I do ask the question, I get the answer, "We need to be proactive to find and fix discrepancies between the financial system and the order entry system before we expose bad data to our customers". That response leads us to a simple UI fix which allows the systems to handle the problem and eliminate the need for a data entry clerk to perform more mind numbing, non-value added processes.

I keep going back to Nick Carr's theory that IT does not matter. If IT is simply taking orders and letting the users design their systems, then Nick is right. Instead, IT needs to help the business meet its objectives by delivering feasible solutions that provide quality, ease of use, and business value. If IT's role is to be servants, then there is no reason for the company to have it's own IT staff. Simply hire cheaper labor to follow orders. Just my 2 cents!

I have been blogging about our BPM and SOA initiative all year long. Yesterday, we deployed our first application, a customer facing B2B portal that spans our sales order process. Although this is just the first iteration of many and we are still a few months away from delivering the features that will give us the big ROI, this was a major milestone for us. So I would like to take this opportunity to share a few things we did right. In part 2, I will discuss a few things I would do different next time.

Things we did right

1. Focused on business not technology - we performed a 90 day business process assessment where we documented current state, brain stormed on future state, and defined a portfolio of projects that each had their own ROI. This allowed us to sell the business on BPM and SOA and helped us secure the funds required to take on SOA.
   
2. We did our homework - We attended conferences, read blogs, researched web sites, collaborated with experience architects, and a got our hands on anything or anyone that had any information about SOA.
3. Thorough POC - We invested a lot of time in an extensive vendor assessment for both the BPM and SOA tools. When we narrowed it down to the short list of vendors we brought them each in for a full day proof of concept. I wrote a piece on CIO.com called the Proof is in the Pudding and another called Beware of Eye Candy that talks about some of the scary things you might find when you start going beyond the Power Point slides and start actually trying to execute processes and services.
4. Surrounded ourselves with talent - We put several of our best people on this project on both the IT and business side. Not only did we look for talent, but we looked for motivated people who embrace change and bought into the vision. We also partnered with an implementation company with years of SOA experience including working on some of the largest SOA implementations in the world. We embedded our architects with our SOA partners to accelerate the learning curve.
   
5. Strong executive support - Our executive sponsor is from the business and the person who went to the top to get the funding for the project. Like a couple of us in IT, she put her career on the line by signing up to deliver substantial ROI numbers over the next four years. You can bet that we have all the support we need. Recently, the CEO declared this one of the key initiatives over the next four years so now the whole company is behind this.
6. Squash resistance instantly - Any time we encountered or were told of resistance or negativity, we immediately addressed it head on. Some of these occurrences turned out to be great learning opportunities while others were the result of lack of buy in. In each case, we tried to understand the root cause and resolve the issue before it spread like a fungus.
7. Short, iterative deliverables - Many companies get themselves into trouble by trying to tackle too much out of the gates. We took a look at all of the projects that we identified and used a combination of portfolio management and a SOA roadmap to determine the priority and size of the scope for each project. By laying out the long term vision, we were able to prioritize which services to build first to maximize reuse and reduce the overall cost of deployment.
8. Sound architecture - We are laying the foundation for a loosely coupled, service enabled architecture that will give us a platform to quickly react to change. We are leveraging both Portal and BPM technology to create new tools that empower our users with self service capabilities, visibility into the workflow, and access to KPIs through Business Activity Monitoring (BAM). We are also leveraging SOA to connect this new front end to our years of legacy systems while hiding the complexity from the users.
9. Having Fun - We are all under intense pressure to deliver the numbers we promised in aggressive time frames. The work is challenging and we had a few "coming to Jesus" meetings along the way, but overall all we are extremely excited and focused on future successes. At the same time we are enjoying being part of an initiative that will transform the company.
   

I know this sounds like a bed of roses but this success has not come easy. In my next post I will describe some of the things that occurred that we will may sure never happen again. The list is as long as the one above.

Zapthink posted an interesting description of a role they call VP of SOA. Todd Biske argued that many of the tasks in this role belong to the Chief Architect and a dedicated role of VP of SOA is unjustified. My view is somewhere in between. As someone trying to fulfill both the role of the Chief Architect and the role Zapthink describes as the VP of SOA, I can honestly say that this can be a lot to juggle. I have fallen victim to becoming so engaged in the VP of SOA role that at times I am not totally fulfilling my duties as the Chief Architect. After all, the Chief Architect is responsible for the architecture of the entire enterprise, which SOA is a subset of. My solution is not to create another high paying role like the VP of SOA but instead give my enterprise architects more responsibility and decision making power to free me up enough to take on SOA and EA. This creates a cascading effect where the tech leads then need to step up to the plate and take on some of the enterprise architects' tasks. This creates opportunities for many people as opposed to one highly paid guru and allows you to build a stronger team over time.

I work in a 200 person IT shop so creating VP positions is harder to come by then if I worked in a 1200 person IT shop. In a larger company, especially one with a distributed IT staff, I can definitely see the justification for a VP of SOA. In a centralized IT shop like the one I work in, I think the VP of SOA and the Chief Architect should be the same person. Your thoughts?

I was reading various blog posts with my Google Reader today and came across a few articles that are riding the excitement of Web 2.0 and appending the "2.0" nomenclature to their subject matter to attract attention. Don't get me wrong, I am a big fan of Web 2.0 and the direction the web is going, but the 2.0 thing has got to go. Here are a few examples of what littered my feed reader today:

• Governance 2.0 - I think governance is on about 84.0 by now.
• Enterprise 2.0 - Fancy name for Web 2.0 at work, call it what it is!
• Sales 2.0 - Sales people using Web 2.0 tools, I feel the nausea kicking in now.
• CRM 2.0 - Mercy!

How many 2.0's can there be? So off to Google I went and searched 2.0. Here are some of the ones I stumbled across:

• Where 2.0 - Location awareness technology; O'Reilly trying to coin another 2.0.
• Business 2.0 - About as creative as Rocky V.
• Television 2.0 - Another reason why I only watch Sports Center.
• Product Development 2.0 - Stop the madness already.
  

But all is not lost. I did find one 2.0 link that I think has merit. Check out this technology to see what I mean!

I was in a strategy meeting last week when our HR representative asked me what the value of Architecture was. Being non technical, he was struggling to understand why we needed an architecture team. My first response was, "Did you just get out of a budget cut meeting?" I was joking but in the back of my mind I couldn't help wonder how many non technical executives were thinking the same. So I set out to write a post about the value of architecture. David Linthicum just posted a timely article called Why Enterprise Architecture is a Corporate Responsibility. In the article he talks about compliance, the need to adapt to business change rapidly, and the need to keep up with competitors who are becoming more agile. At the end of the article there was a great paragraph that I'll call out here...

Thus, without good architectural governance and ongoing corporate management pressure to redirect resources to tactical IT projects, the enterprise architectures continue to become more unnecessarily complex, static, and fragile. What was a mere annoyance only a few years ago, is today a clearly limiting factor in the businesses' ability to create shareholder value. The company can't easily shift into new and emerging markets, acquire companies, and adjust major business processes without a great deal of latency. In some cases, they are completely unable to change. In other words, things are bad and getting worse.

I agree with David on this point. For years, many IT shops ignored the need for EA because it was hard to do, required consistent processes, and cost a good chunk of change to implement. So we built stovepipe application after stovepipe application with no consistency and no integration between systems. We got away with this approach for a number of years but eventually reached the point of diminishing returns. Now with years of developing software with no standards, no consistency, and with no vision, many IT shops have become serious bottlenecks that prevent their companies from quickly jumping on new opportunities and have become a very expensive cost center. Time spent on maintenance and production support keeps increasing and new projects take too long to build. Instead of putting a focus on architecture, many companies look to outsourcing as the answer. If you can't do it right here, good luck doing it right there!

So here is my answer to my HR colleague's question about the value of architecture. Today's business environment is all about speed to market, cost reduction, business optimization and reengineering, and alignment. A good enterprise architecture can help a company meet these objectives. Throw in SOA, and you can meet these objectives while leveraging your years worth of investments in your legacy applications. So what are the advantages of EA?

• Business Alignment - Aligning technology with business opportunities and corporate vision allows IT to create value for the business as opposed to being just a cost center. Knowing where the business is going allows IT to be proactive and implement the right technologies to enable the business to meet its goals.
  
• Reduced maintenance costs - Consistent approach to software development makes it easier to build, test, and maintain. Resource allocation and utilization becomes more cost effective when you can move people across applications. Building consistent software and interfaces makes it easier to leverage your talent pool.
  
• Better control of assets - Planning and roadmaps allow IT to focus on the right resources on the right projects while using the right technologies. Put together plans to retire older technologies that are expensive to maintain and procure new technologies that map up to business objectives.
  
• Speed to market - Once established, EA allows IT to improve delivery cycles through reuse. Of course, this requires IT folks to not get too hung up on frameworks and rely more on people and agile best practices.
  
• Extending the enterprise - Today's demands require IT to connect to customers, partners, and suppliers. Architecting a secure platform for integrating with external entities can be a huge competitive advantage. Doing it wrong can be a disaster.

As David states in his article, as more companies invest in EA and SOA, those companies who choose to continue to build software the old way will struggle to compete. These companies will continue to prove Nick Carr correct when he says "IT does not matter". So for those still sitting on the sidelines because they don't want to invest the time and money that is required to establish an EA, you can pay now or pay big later.

One of the challenges for selling Web 2.0 within the enterprise is explaining the value that it brings. To many long timers within IT, Web 2.0 technology is a play thing that the younger generation uses at home. Many can't comprehend the enormous potential that WEB 2.0 can bring to the table in the form of collective intelligence, social networking, RSS feeds, APIs, and folksonomies. You can show graphs and charts, talk about the intangibles and the tangibles, and power point them to death all day long but the best way to sell Web 2.0 is to do Web 2.0.

Here is an example. I am trying to sell the concepts of enterprise blogs, wikis, and RSS feeds. When I discuss these with many of folks within IT I get way more laughs then I get head nodding. When I sit down with various groups within IT and even within the business to explain SOA, I go directly to some of my blog posts and to specific wiki pages to show visual images to help explain the concepts. Look below for an example (single click for quick slide show, double click to walk through slides with captions).



Just today I was working with our SQA team to explain some of the differences in testing SOA applications versus the traditional client server applications that they are familiar with. I bounced around my blog to find a few posts that helped explain what an ESB is and what the layered approach to distributed computing (SOA) looks like. Tonight I took some of the images off those posts and created the slide show above with Google's Picasa. This is a great example of showing the power of Web 2.0. I put together another album from a presentation I did the other day that discussed leveraging some Web 2.0 tools to improve internal communication.



It you are selling the concept of mashups internally, take one of your internal applications that has a customer database and do a proof of concept that calls the google maps api and displays your customer on a map. This will easily allow you to explain the concepts of mashups to anyone within the organization. Here is an example of looking up ITToolbox.Com headquarters using Google Maps.


View Larger Map

Imagine if you could do this with your CRM application when your sales guy hovers over the customer name! Show the business what Salesforce.com is doing with mashups.

So in the words of fellow blogger James McGovern, don't just give presentations about technology, have conversations. By showing people what the technology can do instead of talking about graphs, numbers, and case studies, you can start a constructive conversation to explore the possibilities. Through conversation, people can bring ideas to the table that you never envisioned. Give it a try and feel free to use this blog post to prove your point. Remember, don't just talk about technology, do technology!

One of the many hats that those of us who are responsible for IT strategy and Enterprise Architecture wear is the evangelist hat. My IT organization has many exciting strategies and initiatives in action today such as....

1. SOA/BPM implementation
2. Creating an official Open Source strategy
3. Leveraging Web 2.0 technologies to improve communication
4. Moving towards agile development
5. Implementing portfolio management

Being in a leadership and architect role, I have to luxury of researching newer technologies (although I do most of it in my "free" time at night). I am not tied to production support which would distract me from my responsibility of "Driving innovation for tomorrow". Many of the people within IT who will be contributors to the above initiatives and recipients of the benefits have a full plate day in and day out and do not have the luxury of having the depth of knowledge on these topics. As a matter of fact, many are far out of touch with what these technologies are and what benefits they can bring to the organization.

Today we had a day long strategy session to go over our OGSM (Objectives, Goals, Strategies, and Measures) for 2008. Our strategies are broken up into four areas and I own the one called "Architecture and Technology". When we got to my section I started talking about Web 2.0 tools like blogs and wikis and received many chuckles when I recommended that we embrace these technologies. When discussing Open Source strategies I needed to emphasize that this is more the Windows vs. Linux. This is about taking a cost effective approach to providing IT and the business with tools and products to enable people to get their jobs done effectively. Instant messaging is another topic that came up. There is still caution and concern about the downside of enterprise instant messaging. I call it the fear of the unknown which is similar to most IT shops first impression of unleashing the internet to their employees.

What became obvious to me today is that for these initiatives to have any chance to succeed, the architecture and technology strategy team is going to first have to spend some time educating the masses on what these technologies are, what the business benefits are, and what the impact will be to our day to day jobs. We must become evangelists, thought leaders, and teachers. For most of the folks in IT, they need us to break down all of the terminology and research into a practical, "Reader's Digest" version that they can consume and understand without interfering with the mounds of work that they are responsible for delivering. One great way of communicating this is through a blog from the architecture and technology team. We will also have to hold various presentations to sell these ideas in both directions. All of these initiatives require a change in behavior which makes educating and communicating the most critical success factors for delivering success.

David Linthicum hit the nail on the head with a recent articled titled Analysts need to Focus More on Architecture, Not Buzzwords. In the article David points out...

The fight here is that Forrester is considering SOA management as something that is very different from SOA governance. However, Gartner thinks that SOA management is a part of SOA governance...

Who cares? I am tired of the SOA buzzword of the day by people so far removed from architecting anything that their goal in life is to be the guy who coined the next hot buzzword. I skim through about 200 blog posts a day and am tired of littering my Google Reader with the next new buzzword like SOA 2.0. As David states in his post,

Not sure it will matter in a few years what you called what technology, but it will matter if you don't create an architecture that will drive your business into the future.

So in protest of the daily dribble the shows up in my reader each day, I pronounce this the era of BOA - Buzzword Oriented Architecture. I will ignore what the analysts have to say and continue to follow the blogs of real life Enterprise Architects like Todd Biske, Nick Malik, James McGovern, Eric Roch, and many others.

Many developers work in a department within IT called Application Development. This name, Application Development, represents the way we used to approach building software. For years, managers herded developers into application teams to work on stovepipe applications like order entry, warehouse & shipping, accounting, inventory, etc. As years passed, many of these applications were being purchased off the shelf like today's CRM and ERP packages. Because of this approach developers started specializing in application silos and third party packages. In many cases, these systems had entirely different data models, user interfaces, and architectures.

Now we are in the age of SOA and we are all working hard to get these legacy systems to talk to each other. Many SOA initiatives are tied to BPM initiatives. The BPM initiatives dissolve the lines between traditional stovepipe applications and allow IT to present the users with new user interfaces that hide the complexity of the backend systems. The users now can do their work through a consistent interface guided by a business centric workflow without knowing that they are accessing multiple legacy systems.

As IT shops invest in SOA to allow their legacy systems to integrate with one another, we should stop building applications and focus our efforts on building business services. We should start building services that can be used by all systems as opposed to building code that is customized to fit a specific application. We should also be proactive and think about the different ways in which a consumer might want to use our services. It is not unlikely that a service can be consumed by a user interface by one system, feed from an XML file from another system, and called directly from another service from an entirely different system. The consumers might be a new system, a legacy system, a third party package, or an external entity like a customer system or SAAS solution.

So as we move away from our traditional stovepipe approach of application development, should we still call our department App Dev? To me, application development is the thought process of yesterday and business services is how we should be thinking today. I'd like to stick a fork in the term application development because to me it represents high maintenance, duplicate efforts, silos, and IT as a cost center. I'd like to call our department Business Services Development which represents flexibility, speed to market, business alignment, and IT as an enabler. What would you call it?