Enterprise Initiatives

In part 1, I discussed the importance of the SOA Evangelist. I also talked about the shift from software development to software engineering. This shift has made the role of the architect critical for the success of any SOA initiative. First, let us talk about the various architect roles required to successfully design an SOA.

Chief Architect - This person, possibly your SOA Evangelist, should have strong technical skills, sound business knowledge, and great leadership skills. Not only should this person understand the ins and outs of SOA, but he/she should be able to explain the value of SOA to the business in business terms, to the CIO in high level technology and business terms, and to the technicians in detailed terms. Depending on the size of the company and the SOA initiative, this person may or may not actively participate in the design. Regardless, this person should be knowledgeable enough to participate in design sessions when called upon. From a leadership perspective, this person is likely the change agent who is the driving force behind establishing and implementing governance, shifting the IT mindset from programming to engineering, establishing the SOA roadmap, and other culture changing elements.

Enterprise Architect - In smaller or midsize companies, the chief architect and the enterprise architect may be one in the same. In bigger companies, there may be more then one EA. The EA has broad domain and business knowledge and works across organizational boundaries to ensure that the architecture meets both the business and IT requirements. Wikipedia says it best when it mentions....

The role of the Enterprise Architect is to take this knowledge and ensure that the business and IT are in alignment. The enterprise architect links the business mission, strategy, and processes of an organization to its IT strategy, and documents this using multiple architectural models or views that show how the current and future needs of an organization will be met in an efficient, sustainable, agile, and adaptable manner.

Domain Architect - The domain architects specialize in specific areas of technology. They are the experts of their domain. Here are a few examples of domains that require specialization:

• Application
• Information
• Security
• Infrastructure
• Business Processes
• Network
• Integration

Once again, the size of the company often dictates how many of these roles exist as a stand alone job function or if they are rolled up into a broader architect role. For example, smaller companies may combine application, information, and integration into one role and infrastructure and network into another role. The key for me is that these roles need to be accounted for regardless if its by one or many people. Each role is critical in successfully architecting a true SOA.

Solution Architect - The solutions architect has hands on experience with specific technologies and even business applications. You may have an architect who specializes in Java, .Net, backend systems, web applications, financial systems, ecommerce systems, distributed processing, etc. Once again, I am advocating that the role is addressed and whether or not a company has one or many people with this title depends on its size and budget.

The Architecture Team
As I described above, the team should consist of the following roles (not necessarily individuals):

• Chief Architect
• Enterprise Architect
• Domain Architects
• Solutions Architects

The number of people filling these roles vary from company to company. In my previous job, a shop of roughly 200 people, our architecture team consisted of myself as a Chief Architect, an EA, a domain architect, and a solutions architect (even though they all had the simple title of "Architect"). There was an Architect over the infrastructure and network that reported into a different structure and a one person security team. My architect team worked closely with the others but it would have been more effective had we all been on the same team with the same goals and objectives.

I have seen a case study at an enterprise architecture conference a few years back where a global SOA initiative for a fortune 100 company had over 100 architects on the team including numerous EAs and even multiple Chief Architects from different business divisions. There is no one way to slice this pie.

Architect Mindset
You can organize the teams anyway you like but one thing you must have is the proper mindset. The architecture team must be focused first on the business drivers that the SOA initiative has set out to solve. If the team loses sight of these drivers then SOA will become an IT project instead of an important initiative for the entire corporation. You must have the business buy-in throughout the project to reap the true benefits of SOA. Please read 8 Winning Characteristics of Successful SOA Implementations which I wrote for CIO.com that summarizes the critical success factors that wer common among the winners of the SOA Consortium/CIO.com SOA Case Study contest earlier this month.

Second, the team needs to ensure that they are not an Ivory Tower architecture team. SOA is too important for architects to be preaching philosophy from the top of their perches. The architect team must be the change agents required to move the organization away from the traditional silo driven application development approach and into a more collaborative engineering approach that focuses on the long term vision not the short term and short sighted approach that many companies practice today.

Third, this team must have an open mind. They need to evaluate current business processes, current IT practices, and current systems, and provide the necessary change and direction required to move the organization forward towards the vision established by the business and IT and reflected in the SOA roadmap. Without changing the way IT approaches development, it is likely that the team won't be able to differentiate between SOA and web services. Education and evangelism is key to understanding the proper way to architect and govern your SOA.

In part three I will discuss the developer role. In part four I will discuss the testers.

One of the challenges of explaining the value of Enterprise Architecture to your organization is the perception that EA is nothing more then a think-tank for high priced architects who practice philosophy from their Ivory Towers. Executives are concerned that the EA team will produce nothing more then nice documents and diagrams and will not contribute to the overall benefit of the company. I have seen three different approaches to EA based on this perception.

Not in my house!
In this scenario, the CIO totally buys into the perceptions and will shut down any attempt to invest in EA. This often occurs when the key decision makers are not highly technical and clearly do not understand the value of EA. IT shops who take this approach tend to work hard and not smart, reinvent the wheel over and over again, struggle to keep up with demands of the business, and lack a flexible architecture to adapt to change.

Half-baked EA
Some companies attempt EA with only "one foot in the water". In this scenario, they believe in the value of EA but fear the perceptions of EA. Instead of addressing the perception issue, they choose to create tactical deliverables so that they can "show" the business concrete evidence that they are delivering value. By giving their architects tactical tasks they take away strategic thinking time required to build out an EA. This becomes a distraction that may entertain the business for a short amount of time but it increases the likeliness of your EA effort to fail. To deliver EA, you must spend the time up front to create the vision, the roadmap, and then methodically produce the deliverables required to deliver the vision.

Full blown EA
These companies have fearless leaders who are able to sell the value of EA and don't let perceptions get in the way of creating real value for the organization. These companies will have to fight the good fight since many people in the organization believe in the Ivory Tower perception and will not be supportive of the initiative. It is critical that the EA group stays focused to the cause and does not get distracted with non strategic initiatives. In other words, they cannot get sucked into the machine! On the flip side, these companies must be very careful that they do not try to over analyze the enterprise and spend months or years creating documents and delivering nothing to the organization.

How do we get there from here?
My advice is to treat EA like any other large culture changing initiative. Follow the steps I highlighted in the post EA, SOA, and Change:

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 architecture
   
8. Govern

The challenge is getting through the first 5 steps in a reasonable amount of time so that you can start showing value in steps 6-7. Here is an important point. The business can never really "see" Enterprise Architecture which is why the half-baked EA methodology is a waste of time. Instead of trying to create deliverables that are visible to the human eye, the EA team should focus on getting the development teams to leverage your EA. EA is under the covers and should not be a puppet show for the business. The business should "feel" the impacts of EA when IT starts improving its time to market, delivering consistent and standard products and services, becomes flexible and agile, and becomes a partner in matching technology to business goals and objectives.

EA is a journey and should be treated as one. It will take years to mature an EA but it shouldn't take years to provide value. There are many books that describe the phases of EA maturity (Enterprise Architecture as a Strategy is my favorite). Each phase can produce real business benefits. Keep the long term goal in mind but set your short term goals on value added deliverables that are stepping stones for the final phases of EA maturity. And most important, stay out of the Ivory Towers!

I have worked on many large enterprise initiatives over the years. Some were successful and some were not. As an avid researcher of my trade, I have also read about many failures of large initiatives. Being the lessons-learned kind of guy that I am, I always try to understand what worked and what didn't so I can make sure that the next enterprise initiative can avoid failure. Whether you are implementing SOA, Enterprise Architecture, forming a PMO, introducing a new programming language, or merging with another company, I have seen a consistent pattern of failure that can be summed in the following 10 categories:

1. Poor Communication
Enterprise projects usually impact a large amount of people. This requires constant communications to all levels of people throughout the organization. A strong communication strategy can help with this. Use a combination of town hall meetings, portals, blogs, group meetings, emails, wikis, bulletin boards, posters, and any mechanism you can think of to get the word out. In larger companies, this can be a full time job for somebody.

2. Underestimating or ignoring impact of change
This is another way of saying poor change management. People need to know WIIFM (what's in it for me). Resistance to change can kill any project. Your initiative must have a champion who carries a lot of clout. The leadership, lead technicians, project managers, and all of the visible people in these projects must be positive forces and constantly promote the vision and the future state. I wrote a post called BPM, SOA, and the Swing Voters that discussed how important it is to stay focused and positive and not to show frustration. People will feed on the attitudes of those leading the initiatives. You must address resistance head on and address people's needs to help them turn the corner. For those who just refuse to buy in and become roadblocks, show them the door!

3. Lack of Leadership
IT Leadership requires excellence in three key areas: Technology, Business, and People. If the leadership is missing any of the three components you are doomed. I have seen some projects succeed where the leader was not technical but relied on strong technical people below them. I have never seen a large enterprise initiative succeed when the leader did not have people skills. Not having the business knowledge often kills projects because the projects tend to be done for the sake of technology and not for business reasons. In this case you can deliver the most impressive solution in the world, but the business might reject it because their needs were not taken into consideration. The leader must work just as hard if not harder then the people on the team. I have witnessed one "leader" assign his team a ton of work over the weekend and then left at 5pm on Friday and said "See you Monday". That created an all out revolt. The leader must have integrity or nobody will follow.

4. Lack of strong executive sponsorship
For these projects to succeed you must have somebody high up in the organization with a lot of clout. There will be many obstacles to overcome and key decisions to make. You need somebody strong to help make and enforce those decisions and remove major hurdles so the team can get the work done. This is a critical part of change management.

5. Poor project management
Scope creep is a project killer. Managing scope and requirements are the key to any project. Often, large enterprise initiatives have a ton of logistics that need to be identified and managed accordingly. These initiatives also tend to span multiple teams across various departments. The project manager must coordinate all this and effectively communicate to people at all levels. And don't forget risk management!

6. Poor Planning
This could also fall into a category of unrealistic expectations. Initiatives like SOA require a well thought out strategy. Many IT shops do not have the patience for this and rush into their project head first without a clue of how to actually accomplish their goals. When it fails they claim that SOA doesn't work. If you are going to take on a big culture changing technical project take the time up front to do the necessary research and create a roadmap. Then put a plan together to get you from initiation to implementation.

7. Trying to do it cheap
Another common mistake. Organizations want it all, but they don't want to invest the time and money. I have seen many projects get completed using this strategy, but they almost always run over budget, are late, are missing many features, and have many various quality or process issues due to the quick-n-dirty approach. Remember, the dirty stays around long after the quick is gone. Doing things cheap often costs more in the long run. I have witnessed many projects that didn't fund the appropriate number and types of resources. You wind up not creating documentation, not having the bandwidth to sufficiently test all of the use cases, not having time to architect it right, and you burn people out in the process. Another issue is that underfunded projects usually don't provide the team with the necessary tools to do the job and do not prepare the organization for life after rollout. Even worse, you may wind up picking the wrong vendor, whether it is software or professional services. Picking the wrong vendor can be disastrous.

8. Lack of technical knowledge
I'll use Enterprise Architecture as an example here. If the person leading an EA initiative does not have a solid understanding of architecture, application development, security, infrastructure, process, and the business, you might as well not even start this initiative. You can have all of the leadership and communication skills in the world but if you lack the technical know how you are doomed. Many enterprise initiatives are very expensive undertakings. Don't pick a leader with the "I stayed at the Holiday Inn Express" mentality. You wouldn't ask me to remove your appendix so why would you have somebody with little or no knowledge of the technology at hand lead your enterprise initiative.

9. Lack of sound business case
You can get all of the other issues right but if your solution has no business context then you are wasting your time. I have seen this happen with many SOA projects. IT teams with great intentions go off into their ivory towers for months or years and come out with tons of great documents (usually outdated) and a nice service oriented architecture. Then they try to convince the business to use it. Good luck. Justify these initiatives with business drivers. I have beaten this horse to death on this blog (here, here, and here).

10. Poor vendor management
I have seen this happen far too many times. Somebody hires a high priced group of consultants and let's them run wild. Consultants goals are similar to your goals but that is not a good thing. Both the consultants and your goals are to make as much money as possible for the company. The difference is you are trying to maximize profits for your company and they are trying to maximize profits for their company. If you don't manage them closely they will succeed at their goal and you will fail at yours. Also, the consultants will not have to stick around to support what they build, but your team will. You should make sure that what they build meets your requirements, your standards, your needs, and your timelines.

Summary
I have a saying from my 20+ years of working on IT projects. It goes like this.

"I have worked on so many projects that I know all of the things NOT to do."

That's the easy part. Knowing what to do is much harder. I'll leave you with this post called EA, SOA, and Change which has a very successful formula for enterprise initiatives.

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, add incremental value
   
8. Govern

Recently, I provided senior management with a presentation of the value of Enterprise Architecture. For those of you who are tasked with a similar assignment, I thought I would share an example that has worked for me. Keep in mind that some of the bullets are specific to my environment, but hopefully the presentation gives a perspective of how to explain EA in simple terms to people who have never been exposed to EA. I did alter the original presentation to try to make it as generic as possible for my readers.

Feel free to critique this or use it for your own benefit.

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.

Bringing an Enterprise Architecture to your company can be a battle, especially if the current culture is used to application silos and has no clear picture of the true costs and performance of IT. The most challenging part of implementing EA is dealing with culture change. I stumbled across a great article today in the current issue of the Architecture and Governance magazine. Here is an important quote from this article:

“Twenty percent of our success is the new technology that we embrace . . . but 80 percent of our success is in the culture of our company.”

The article goes on to describe characteristics of a culture where EA is accepted:

• Collaborative teams vs. stovepipe
• Information sharing vs. hoarding
• People-oriented vs. bottom line focus
• Emphasis on standardization vs. technological differentiation
• Adherence to governance vs. “acting first and asking permission later”
• Business focus vs. technology for technology sake
• Performance measure (accountability) vs. "seat of the pants"

Here is my take. If you have a culture that fits the above description, you probably already have a well established EA. For the rest of us, we need to identify which characteristic(s) we are missing and devise a plan to change the mindset. Obviously, the more characteristics of your culture that are undesirable for an EA, the harder your job will be. David Linthicum wrote this piece yesterday called Why Enterprise Architects Continue to Fall Short with SOA…and Enterprise Architecture. In this article he points out three reasons why architects fail trying to deliver SOA. The last one is fear of change.

Fear change. If things are bad, than change is typically good. Unfortunately, change also means risk, and risk is something people typically don't like. The fact of the matter is that people are rewarded for maintaining more so than improving, and thus how many of the enterprise architectures out there are now layers upon layers of tactical one-off solutions designed to "keep things going a few more years." Somebody needs to have the political will to figure out a long term solution, using sound enterprise architecture approaches, including SOA.

Dave's point "Somebody needs to have the political will to figure out a long term solution" is what I am referring to as "fighting the good fight". As enterprise architects, chief architects, CIOs, and CTOs, we owe it to our respective companies to deliver value, efficiencies, and enable our business partners to achieve their goals. Too often, IT shops have become bogged down in keeping the lights on because they always take the quick and dirty route to solving problems. Always remember, the dirty hangs around long after the quick is gone. It is time to fight the good fight and build an architecture that allows your IT shop to be responsive to the business (agile) while building a sustainable architecture that supports both short and long term needs.

Last week I wrote a post called "Do you have an Architect personality?". James McGovern asked that I follow it up with a post about an architect's abilities. One of the most overlooked abilities of an architect is the ability to lead through change. Too often, the architect role is looked upon as strictly a technology role. This may be true if an architect works on a well established EA. But for most of us, either we are trying to implement EA or we are in the early stages of EA maturity and are still battling with politics, nay sayers, and resistance. Architects must be leaders and help explain WIIFM (what's in it for me) to each person who still has not joined hands with EA. Why must we change? What value does this bring? How will my job change? How will we have time to do it this way? These are all familiar questions that architects are faced with.

So what are some of the abilities that architects need?

• Emotional Intelligence - ability to perceive, assess, and manage the emotions of yourself or others.
• Leadership - ability to affect human behavior to accomplish a mission or goal
• Effectively Communicate - ability to clearly articulate (verbal and written) one's message. Includes ability to persuade, negotiate, articulate, sell, and others.
• Intelligence - ability to learn and retain information about new technologies, processes, and solutions.
• Problem Solving - Find solutions to complex problems, both technical and non-technical
  
• Vision/Strategic - Ability to predict future patterns and plan accordingly. Create roadmaps and action plans for accomplishing goals.

This is a short list. I could go on forever but these are the key ones. To fight the good fight, one must have the determination and stamina to move beyond the daily grind and strive for the end goal which is to establish a functional and mature EA. If one chooses the easy way out ("that will never happen here" or "they are not ready for this yet"), then they are not doing the role of an architect any justice. Instead, they are simply a senior developer with a fancy title.

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.

Want to know the latest techniques, tips, and tools for SOA adoption and best practices? Want to step beyond simply implementing Services to making SOA a loosely-coupled reality? Want to learn from industry practitioners on the best ways to guarantee SOA success?

We recently contracted with Zapthink to set up a four day SOA Bootcamp at our corporate headquarters in St. Petersburg, FL from February 26-29. The class can hold up to 40 people. There is plenty of open slots left. If you are interested please shoot me an email for more information. If your team sends more then three people then volume discounts apply. I need about five more folks to meet the minimum requirements for the class.

This is a great opportunity to get some intense training and to network with peers in the Tampa Bay area. For those of you from out of town who want to escape the harsh winters and enjoy the Florida sun, there are hotels within walking distance to the facilities.

Here's a plug for my friends at Zapthink:

Attend ZapThink's Practical SOA events in 2008! The best of the best in the world of SOA take you through concepts, business issues, approaches, and technology to make SOA work within your organization. We don't focus on the hype and the folks who have products to push, but on the “brass tacks” of making SOA work for you.

Zapthink's Seven PSOA Events:

• Practical SOA: Frankfurt, Germany January 15, 2008 (http://www.zapthink.com/practicalsoa/germany)
  
• Practical SOA: Energy and Utilities, Houston, TX February 5, 2008 (http://www.zapthink.com/practicalsoa/energy)
• Practical SOA for Pharmaceutical and Health Care Industries, Woodbury, NJ March 3, 2008 (http://www.zapthink.com/practicalsoa/pharma)
• Practical SOA: Australia, Canberra, Australia, March 18, 2008 (http://www.zapthink.com/practicalsoa/australia)
• Practical SOA: Governance, Quality, and Management, New York, NY March 25, 2008 (http://www.zapthink.com/practicalsoa/gqm)
• Practical SOA: London, UK, April 22, 2008 (http://www.zapthink.com/practicalsoa/london)
• Practical SOA: Insurance, Las Vegas, NV -- Co-Located with ACORD/LOMA 2008 May 16, 2008 (http://www.zapthink.com/practicalsoa/insurance)

I just posted my top 10 posts for 2007 and all of them were related to Linux and open source (thanks Digg!). But my real passion for writing is enterprise initiatives like SOA, BPM, Enterprise Architecture, Project and Portfolio Management, Outsourcing, and any initiative that requires a combination of leadership, technical knowledge, and people skills. So here is my top 10 posts for all non open source topics in 2007:

1. How did we become a Dilbert cartoon?
2. What does it all mean?
3. Selling SOA - a True Story
4. Top 5 Bone Head Moves
5. Outsourcing vs. Offshoring
6. Adobe Flex beats Silverlight every time
   
7. Zap Think's Who's Killing SOA
8. Another Benefit of SOA - Career Path
9. Why are you still generating reports?
10. SOA and BPM Consolidation

I would also like to list a few of my lesson learned posts because I believe these types of posts add the most value to the community.

1. SOA Lessons Learned
2. Lessons Learned from our first SOA implementation - part 1
   
3. Lessons Learned from our first SOA implementation - part 2

Happy Holidays!

Over the last 18-24 months I have researched and taken on a number of Enterprise Initiatives such as Enterprise Architecture, BPM, SOA, and agile development to name a few. As I researched each topic I found tons of articles recommending to steer far away from each initiative. The common theme is that it is expensive, too hard to do, and most initiatives fall. Today I was researching Enterprise Metadata and many of the search results pointed towards doom and failure.

Why is there so much failure with these all important initiatives? I did some research and found that a large amount of normal projects fail at equally high rates. The enterprise initiatives are just more visible and usually require a significant upfront investment. So what are the common reasons for failed projects? An article at Gantthead.com provides the following list:

• Inadequately trained and/or inexperienced project managers
• Failure to set and manage expectations
• Poor leadership at any and all levels
• Failure to adequately identify, document and track requirements
• Poor plans and planning processes
• Poor effort estimation
• Cultural and ethical misalignment
• Misalignment between the project team and the business or other organization it serves
• Inadequate or misused methods
• Inadequate communication, including progress tracking and reporting

For enterprise initiatives I would add these:

• Lack of strong executive sponsorship
  
• Unrealistic scope ("boiling the ocean")
  
• Lack of governance
  

So the next time you start researching a large IT initiative and you see all the negative publicity about your chances of success, ask yourself these questions:

1. Do we have the leadership required to take on this project?
2. Do we have enough change agents to change our culture?
3. Will we be able to get enough funding to adequately meet our objectives?
4. Will we get the support from the executives and/or the business?

If the answer to any of these questions is "no", then you might want to listen to the warnings from the articles. If the answers to all of these are "yes", then it all comes down to how good of a plan you put together and how well you execute the plan. Don't be risk adverse and let fear get in the way.

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

A colleague of mine uses a great analogy to explain the purpose of an ESB (Enterprise Service Bus). He starts by reminding us of how PCs work. The PCI Local Bus within the PC is a high speed channel for providing a centralized mechanism for connecting multiple hardware components within a PC. Without the bus, the inside of your PC would look like a spider web of wires with each component having to connect to all other components. The following diagram shows a simplified view of a PCI local bus.


The ESB performs a similar function within a service oriented architecture (SOA). When architected correctly, the ESB becomes the centralized mechanism for controlling all messages and events that occur between the various layers of the architecture. The ESB centralizes security, routing, transformation, invocation, and service management. Look at the diagram below and see how it looks similar to the PCI local bus.


I have seen a lot more head nodding and a lot less glass eyes when using this analogy to explain the role of the ESB. Give it a try.

I posted my opinion on CIO.com (The Role of the Enterprise Architect). Here is a summary...

The EA should know how to code and should have spent many years developing, designing, and managing technical projects. So when I say that the EA should not be coding, that does not mean the EA doesn't know how to code.

With that said, the EA's focus should be on strategy and vision. The architects below the EA should turn the strategy and visions into reality.

I have read many blogs that argue both sides of this question. James McGovern's article states:

You probably have ran across architects that don't code. Hopefully you aren't one of them...

I am hoping that he truly means architects and not Enterprise Architects (EA).

Colin White has a good article called Architects don’t code, they whiteboard. I tend to agree with his stance on this topic.

Here is another article by Simon Brown who has a similar opinion.

On Bill Barr's blog, Agile Enterprise Architecture, Bill phrases it slightly different. He says that EAs should not write production code but...

When it comes time to talk to people about a new idea, get feedback and even sell the idea, that's when a page or two of some clearly written examples are worth a thousand powerpoint slides.

What do you think?

So many exciting changes are happening in the world of IT today. Look at all the hot topics from around the net that we read about each day:

• Virtualization
• Web 2.0
• SOA
• BPM
• Saas
• Outsourcing
• Open Source
  
• Mobile Computing
• Event Driven Architectures
• Mashups
• Collective Intelligence
• Super fast chip technology
  

What does this all mean to the future of IT? Most of these technologies (if done right) will impact the workplace in a variety of ways. Some of these technologies will enable people to be fully functional from remote locations (Mobile Computing, Web 2.0, Mashups, Collective Intelligence). Some of these technologies will eliminate human processes both in the business (BPM, SOA, Event Driven Architectures) and IT (Virtualization, Outsourcing, SaaS). Others will make us less dependent on the big vendors (Open Source, Virtualization). Then there are the advancements in chip technology and memory which can really rock our world. Can you say diskless PCs?

So as I read article after article, day after day, I begin to wonder what this all means to the working people in IT. I can be pessimistic about the future of IT and paint a picture that looks like this:

• Mass virtualization - elimination of many systems administration and networking jobs
• Mass Outsourcing - Most of development farmed out due to cost effectiveness of remote development (both onshore and offshore)
• Less internal development - Reduction of development jobs due to effective end user tools (BPM, Mashups, Web 2.0), external development (Outsourcing, SaaS), and improved collaboration and automation (Collective Intelligence, Event Driven Architectures, SOA)
  

Or I could take an optimistic view of the future of IT:

• Business Alignment - business heavily relies on IT for automating and streamlining business processes (BPM, SOA, Event Driven Architectures)
  
• Enterprise architecture - Architecture becomes key differentiator and enabler
  
• Rapid development, less maintenance - Tools (Mashups, Web 2.0) and architecture provide a platform to rapidly deploy. IT delivers loosely couple services, not proprietary monolithic applications, which reduces maintenance and allows for more new development.
• Cost effective computing - Business looks to IT as a partner and an enabler instead of a cost center. IT makes the business efficient (Mobile Computing, fast chip technology, collective intelligence) while being cost effective (SaaS, Virtualization, Out Sourcing, Open Source, BPM, etc.).

My belief is that it will come down to the IT leadership, mainly the CIO. The CIO needs to measure and promote the value of the IT department as we move through these dramatic changes in technology over the next few years. He or she must be a trusted business partner to the CEO, CFO, and COO. IT should be proactive and start implementing these technologies (where it makes sense) to enable the business, as opposed to waiting for the business to tell IT to implement these technologies to reduce costs and headcount.

So what is your view of the future of IT? Is it pessimistic or optimistic? If it is pessimistic, what are you doing to change it?

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 4, I will focus on Lack of Metrics.

Many IT shops are stuck in maintenance mode and live the life of fire fighting and working hard instead of working smart. These shops struggle to meet the demands of the business and spend most of their time and money keeping the lights on. The business is reluctant to release more funds to IT to fix their issues because they don't see the value that they are getting for their current spend in IT. Your CEO is telling you to do more with less and you are asking for more resources to stay afloat. What gives?

I have heard the grumbling within IT wondering why the business "doesn't get it" or why "they can't see that we need resources". The business has a full time job and expects IT to do their job. They don't have the time to sympathize with IT because they have their own battles to fight. What you have to do to get their attention is to tell a meaningful story that is based on facts (metrics) and discussed in business terms (dollars). So before spending another day complaining about the current state of affairs, start brainstorming about what metrics you should be collecting to allow yourself to paint a picture for the business.

Metrics can be used a couple of ways. First of all, I am not a big fan of coming up with metrics to try to measure the productivity of developers (function points, lines of code, etc.). These types of measurements do more harm then good. I am not looking for metrics that show a distrust in your teams ability to do their jobs. I am looking for metrics that can capture opportunities to make improvements in the enterprise. Tracking where time is being spent can be a valuable exercise. You should know how much time you are spending on product support and maintenance and put plans in place to reduce these numbers by some percentage each year. You should also measure defect types and severity by application so you can put task forces in motion to improve the problem areas. If you ever want to get out of support hell, you must be proactive.

If the business does not think that IT is providing value, you can use metrics to show them otherwise. Metrics about availability and uptime, SLAs, change requests implemented, money saved due to process or performance improvements, and many others can highlight the things that IT brings to the table. Create executive level dashboards that sell the value of IT real time. One of IT's biggest faults is that IT rarely celebrates its success stories. IT falls victim to the "what have you done for me lately" routine. If you got it, flaunt it!

Once you have your metrics in place, you can start the long journey of continuous improvement. Attack your top problem areas and tie your metrics to dollars. The business listens and understands money. They typically don't listen to or understand technology. When you do need to go to the well to ask for resources, you should have plenty of facts that you can tie to dollars to sell your story. Despite some of the griping within the gallows of IT, the business is not blind. IT has just never provided them with enough data to see the light.

Nick Carr created one of the longest running questions I have ever seen when he wrote his book Does IT Matter back in 2004. There has been so much discussion arguing for both sides of the answer including this article from Harvard's Andrew McAfee. I believe that a key differentiator for a company is the business processes. For IT to Matter, IT must create an architecture that supports the business's need to dynamically change and customize their processes. This allows the business to be more self sufficient and agile, which leads to a better user experience and faster time to market.

This is why the BPMS and SOA vendors are cashing in right now. Many IT executives are starting to understand that IT needs to be more of a partner to the business then a cost of doing business. BPMS solutions allow IT to provide tools for the business to rapidly deploy new systems that can have a huge impact on the bottom line by:

• reducing costs through process reengineering
• identifying bottlenecks and providing what-if analytics for ongoing process improvement
• providing robust, AJAX & web enabled user interfaces
  
• providing visibility into performance metrics with built in business intelligence tools
• providing self service capabilities for the end users, thus reducing the dependency on IT resources

The smart IT executives are leveraging SOA to allow the BPMS tools to talk to the existing legacy systems by providing a service layer that acts as a bridge between the user interface and the backend systems. This allows IT to rapidly deploy new systems without having to throw away the huge investments made over the years on their existing systems.

So to make a long story short. Does IT Matter? It can matter if IT recognizes that "Process is King" and that the business and IT need to work hand in hand to provide solutions that create a competitive advantage.

I spent the last two days in Weston, FL. attending various BPM and SOA related lectures. One session I enjoyed was George Paras's "Connecting the Dots: Establishing THE Enterprise Perspective". George is the editor-in-chief for the Architecture and Governance Magazine.

George reminded us that as architects we should think, act, and behave as business people. Everything we do as architects should be geared around value creation by affecting change in the name of product innovation, process transformation, technology transformation, and business transformation. In other words, we need to enable the business to be better, faster, more efficient, better informed, etc.

He then went on to point out that one of the reasons that it is so hard to create business value these days is because our technology and our business processes have become so complex. He showed us one slide that states, "Complexity INHIBITS Change....Complexity consequently INHIBITS Business Value". In my opinion, as we begin to model both our operational and technical architectures, we must make it a goal to minimize the complexity and subscribe to the KISS (Keep It Simple Stupid!) methodology.

The last golden nugget that I took away from George's presentation was about maintaining balance. George talked about how companies struggle to make progress towards establishing an enterprise architecture because the business demands so many tactical projects yielding only short term gains. The chief architect or architecture group must figure out how to get the company to start thinking strategically which yields long term gains. But be careful, you need to strike a balance between tactical and strategic. The business cannot stop while you go off for 6-12 months to create an enterprise architecture.

George's answer to the "Balancing Act" is the Managed Portfolio. The Managed Portfolio combines :

• Enterprise Strategy & Planning
• Project Portfolio Management
• Enterprise Architecture

The leaders of these three groups need to be in sync and must have shared goals geared around value creation.

During a break, I had a chance to speak to George (us Greeks need to stick together). I discussed my project and our approach to implement SOA only for the services required to support our BPM initiative, as opposed to creating a full blown SOA implementation. He agreed that we were on the right path which will make me sleep a little better tonight. I then handed him my last business card which was crumpled and stained with spaghetti sauce. Talk about great first impressions!

There were many other meaningful lectures at the show, but this was the best one to blog about.

A good buddy of mine forwarded me this article from eWeek by Deborah Perelman. The following quote from the article summarizes the content: “In the simplest terms: too many IT workplaces have become Dilbert-ized—micromanaged, bureaucratic and stifled creatively. It's become an environment where busy work is praised and morale is low.” The article talks about IT as a commodity with trends in outsourcing. Flextronics CEO, Michael Marks, goes one step further in this Businessweek Online article Design is a Commodity. He recommends outsourcing the engineering process for electronics.

How did we get here? In my opinion, IT has done this to itself through the years due to the following reasons:

1) Not working closely with the business

2) Inability to successfully manage projects

Let’s talk about the first point. In the 60’s and 70’s, the business was dependent on IT for information. There were no high powered PCs and the Internet was not for commercial use. Most of what IT worked on in the public sector was business enabling applications. During the 80’s and 90’s, huge advancements in processor speed, memory, and disk technology enabled personal computers to do the work of the massive mainframes from the previous decades. Then the internet came of age which changed the way people and businesses interact with one another. These two important technology advancements changed business for the better but not without consequences. The days of IT being in control with centralized and reliable systems gave way to the complex, distributed, and multi platform environments that we live in today. This in turn, directed a lot of IT’s attention towards infrastructure projects. In today’s world, a large portion of IT budgets go into projects and services that keep the lights on for the company (email, voice & telecommunications, security, compliance, etc.) and do not contribute to additional revenue. In addition, software vendors started delivering shrink wrapped solutions (ERP, CRM, Financial applications, etc.) that was not feasible for companies to build internally. I believe these factors have all contributed to the fact that many IT shops have become disconnected and/or out of touch or alignment with the business. IT has become perceived more as a cost center then an enabler. Employees have become known as what Catbert calls “Headcount”.

Point #2. The PMI Institute states that 72% of IT projects they studied were late, over budget, lacking functionality, or never delivered. Of the 28% “successful” projects, 45% were over budget and 68% took longer then planned. These numbers are frightening! Lack of project management best practices have caused many companies to lose faith in IT. Many business units have started buying their own software packages or paying outside vendors to solve their business problems. This is another reason why IT and the business have become unaligned.

When a company views IT as an expense and not as an enabler, the IT shop becomes a poster child for Dilbert cartoons. Companies tend to look for ways to reduce or eliminate expenses. Once you view your employees as “headcount”, the creativity, passion, and drive gets drained right out of you.

So is IT doomed? Many experts believe that in order for companies to stay competitive and survive in the upcoming years, IT needs to focus on business processes. In the article, The How, Why, and Where of Future I.T., Mark Gibb’s states that, “I.T. has to be able to show that it delivers a real return on investment.” To accomplish that, I believe that IT should start embracing:

1) Project management – to improve delivery and communication

2) Portfolio management – to maximize IT investments, align priorities w/business, and control workloads

3) Business process management – to optimize and automate business processes

4) Enterprise architecture – to align technology with corporate goals and strategies

5) Change management - to manage change and impacts on people and processes

6) Agile development – to deliver value early and often

What are your thoughts?