I wanted to take a moment to mention something that I have been participating in the past several months, but haven't written about yet. One of the real benefits of working at Microsoft is how much we give back to the community. Microsoft matches time and money that I donate to charitable organizations, and also tries to be a good corporate citizen. As a part of this effort Microsoft set up Search and Give. This is a way of encouraging people to use the Live search engine while contributing money to their favorite charities. I personally have Search and Give set-up to contribute money to the Monte Cristo Elementary Parent Group which I am a member of. That was as I search for items on the internet I am also providing funding towards the parent group which provides many educational materials for the students at my childrens school.

Now I realize there are people who would claim this is a publicity stunt to get people using the Live search engine. That may be true, but at the end of the day so what? Microsoft has made a concerted effort to improve the functionality of Live search to the point where the differences with Google are miniscule. Ultimately if the search experience is the same, or better in many cases, what is the downside of using Live over Google and generate funds for your favorite charitable organizations? The other thing to do of course is to get other people to use Search and Give as well. The more people that use it the more money the charities get and that is ultimately good for them.

I would also encourage you to try out Live search. The Live team has added many new functionality and performance changes over this last year. They are truly trying to make the search experience more than just getting list of links back, but actually providing information that will enrich the user experience. If you are still hesitant to use Search and Give I would ask you to go and read the FAQ about it. See what Microsoft is doing as a company and how you can help your favorite charities.

This post has nothing to do with the Zune device itself as I really like my Zune and enjoying listening to it, but has more to do with the state of digital music. I have a Zune Pass which means that for a certain amount of money each month I am renting the music. I like this over having to buy everything in my collection as it allows me to try out songs and albums I might never take a chance on otherwise. It also provides a steady stream of money to the music business since I am not likely to purchase these albums anyway.

The problem is that the record labels can pull the rights to the music at any time. On Friday I was driving home from work, and plugged my Zune into my car stereo system. I quickly discovered that a large amount of the music I listen to has be pulled from the Zune Marketplace. On my Zune itself I get a message that, "The item is missing or can't be played." When I logged into my Zune account on my computer and tried to play the same song I get the following:

This happened with several hundred songs on my Zune. I consider this a bad experience for the customer. Now I realize that one could argue that with DVDs for example that a rental company like Blockbuster or Netflix might pull a movie at any time and that movie would no longer be available for rental. Normally they do this due to the lack a popularity of a title though, and especially with Netflix, not due to a lack of shelf space. The key difference to me though is that a DVD doesn't get pulled once I have rented it and have it at home. I don't get a DVD from Netflix for example that plays for the first day I have it, but never again. The same cannot be said for digital music.

Now if a particular song was completely pulled I could probably understand, although I still wouldn't be happy about it, but it seems so random. As an example one song that stopped working on Friday is "Angel" by Sarah McLachlan on the Mirrorball: The Complete Concert album. It looks like the record label has decided that most of the songs on this album are only available for purchase. The song itself though is available via the Zune Pass on a different album. So if I want to keep the song on my Zune I have to delete the one I have that is no longer working and go and get a new version of the same song if I still want to listen to it. That is a horrible customer experience and explains why people are so willing to steal from the record companies.

Now perhaps I am wrong, but I can't imagine there is a huge demand for a song on an album that was released a few years ago. Why they would decide that the only way to listen to this song now is to purchase it doesn't make any sense. I get why they might do this with newer songs, but not with one that is much less popular today than when it came out. I know that some of you might ask why I don't just purchase the song, and it really comes down to a question of value for me. There are some songs that I like so much I have paid for and purchased them. Many songs however have value to me, but are not worth 79 Zune points for me to purchase. I might be willing to pay 19 - 29 points for the song, but not more.

Ideally the record companies would stop changing their minds ab0out which songs are available week to week, and instead just make the majority of their offerings rentable permanently so they would at least get some income from each song or notify the customers through the software or device ahead of time so that they can decide how to handle a pending removal of a song. Perhaps the Zune software could have a tab that shows songs that will expire in the next 2 weeks and present the customer with alternatives on handling the change. Here are some ideas.

1. Purchase the song for a discounted price.
2. Inform the customer of a different version of the song that is available for rental. Let them choose if they want to download this version and modify any play lists accordingly.
3. Allow for current renters of the song to keep renting it, but no longer allow new users to download it.
4. Especially with older songs, just leave the rental rights unchanged.
5. At the very minimum give me a view that shows all of the songs that have been removed so I can easily get them out of my player and software.

I would hope that the people at Apple and Microsoft would work with the record companies and try to get these types of issues resolved. I think that for normal customers this experience ends up reflecting badly on the device itself and the company making it rather than on the record labels where the blame really lies. It stuns me that the music industry cannot get their act together and realize we are not all music thieves. Many of us are willing to pay to listen to music we like, and making things available for rent is a good model for them. I'd be interested in some other thoughts here.

As most of you know, today is Bill Gates last day as a full time Microsoft employee. He is moving on to focus his full time efforts on the Bill and Melinda Gates Foundation. This will be an interesting time for Microsoft. One real positive we have going for us though is our senior leadership. I, for one, have full confidence in their ability to direct our efforts to make great software and look for new opportunities to provide our services.

As Bill leaves, like many, I reflect on his contributions to the information technology industry. Most of my career was spent working with Unix systems so for a long time I spent much of my time ripping on Microsoft in general and Gates specifically. As I have progressed in my career though I have come to understand just how visionary he was and is. I also admire the work he has done throughout the world with his money and his desire to help people.

As he leaves today I just want to thank him for his hard work in helping get technology to where it is today and wish him well as he uses his foundation to help people. Thank you Bill!

I haven't written much about technology recently, but based on a meeting I attended yesterday I started thinking about what it's like to work in Microsoft IT. I find that it is one of the most unique environments to work in for several reasons.

Advantages

1. We don't spend lots of time deciding on platforms and software packages to use. Obviously we are going to use Windows Servers and Microsoft technology everywhere that we can. I consider this a plus, because I have seen projects have to make major shifts in other places I've worked based on the current management's perception of certain hardware and software vendors.
2. We have sufficient resources to make projects happen. IT is a cost at most companies. Since there is no revenue generated by the IT Department there is always pressure to keep costs low in order to maximize revenue. Since the IT department here helps test "dogfood" the software we are actually contributing to making the products better and thus contributing to revenue.
3. IT has a direct impact on the features and changes that are made in our software. Since we use the products, often while they are still in Alpha or Beta testing, we get to provide useful feedback to the product groups on how we think certain features work or don't work.
4. One of my favorite items is that we have an incentive to do things right. Since we need the ability to go into our customers and help them with the implementation of our products it is important that we can use our own set-up and experiences as an example to our customers. I believe this is our greatest asset although we probably don't utilize it as much as we could. If we expect people to use our products we need to demonstrate how to use them in a "world class" way.

Disadvantages

1. I am sure it's apparent, but we have to use our own software. In 99% of cases this is fine of course as our products are very good and accomplish what we need. Of course there are cases where there are other products on the market that our better than what we currently have. In another IT shop one would just have to convince the management to use the better software, and provide business justification for the purchase, but here we need to use our products and provide feedback on missing/broken features.
2. Working in a software company can also be a challenge. When we work with teams there is often the mentality that they will just write the needed functionality themselves rather than take a dependency on another product or service. In other IT departments I have been in this isn't always an option, but here it seems easier to justify writing your own code.
3. It can also be difficult to be in the same company as the team who wrote the product. Mostly the relationships here are good, but I'm not sure that we always get the same amount of attention that a customer would when reporting a defect or requesting a product enhancement. This varies by team of course, but can be a challenge at times.

Overall though, I really enjoy my time here at Microsoft. There are many incredibly smart people and I get challenged each day. The culture was a bit of a shock when I started, but I am now getting much more sued to how we do things. I can also say that I feel very well treated as an employee. We get wonderful benefits of course, but also there are many small things that make me feel valued to the company. It is also great to work for a company that is involved in so many different areas as that gives me great options to direct my career into the areas I'm interested in.

• I am a big fan of PowerShell, and I know Harry likes it as well. Of course I have aliased many of the commands so they appear more Unix like. I mention this because David Aiken mentions a new product for PowerShell called NetCmdlets produced by N Software. I downloaded a trial and have been impressed so far. If you use PowerShell it might be worth giving this a look.
• The New Yorker has an interesting article about feature choices in technology. Basically it comes down to customers choose products with more features and customization options if given the choice, but when they actually have to use the products they prefer simplicity. I think that is something lost on those of us who design things. Giving users every possible option can make our products seem more difficult to use over simpler less feature rich choices. (via Coding Horror)
• Well it took longer than some may have guessed, but Microsoft has been sued over the name Vista by a French TV company. Apparently they were going to launch a television station with the same name. I wonder what the courts will decide since apparently the TV company didn't register the name in the software category.

• I am a few days behind on this, but Joe McKendrick writes an interesting piece on if businesspeople are begging for SOA. It is fascinating because I believe that SOA should come from the business, not because of the delivery mechanism, but because of the results. If services will truly make a business more adaptable and responsive to change shouldn't all business people desire those results? At the same time they don't care how that end is achieved, just that it is. That's where we in the IT industry need to do a better job of working out the details amongst ourselves and show the business how SOA can benefit them. Once we do that we should see more SOA adoptions go smoother and real ROI can be seen.
• Joel Dehlin has blogged on the myth of youth being the ones that use instant messaging, publish and read blogs, participate in social networks, etc. I agree that the technology has been integrated into every layer of society. If you have ever been at the airport or at a Starbucks you know what I mean. Who is it exactly that has a Crackberry addiction? It seems technology has really become a part of our culture, and that it's not just one age group that is adopting the changes.
• Visual Studio 2008 shell was announced at TechEd yesterday. Even Harry who was on-site missed the release, but it certainly looks cool.
• If you have ever met me you would quickly discover I have quite a background in Unix. That being the case I couldn't ignore the news that Sun is releasing new blades for the desktop. I had a blade on my desk for several years and it was really a nice system to use. For those that would bash me since I work at Microsoft now I will just say that when you support Solaris boxes, having one on your desk is quite helpful. I don't take sides in the Holy War. :-) (via Scoble)

Due to a temporary reassignment this morning, I spent my usual blogging time moving all of my computer equipment from one cube to another.

• Sam Gentile writes about the ALT.NET moniker. My favorite of his principles is number 4 where he discusses the importance of tools versus principles and knowledge. I really agree that knowledge and principles are more important because the best tools in the world can't help us if we don't know how and when to use them.
• I find Mark Cuban's ideas (here and here) about how advertising on the Internet is different than traditional media advertising. He points out that the ability of a provider to deliver higher simultaneous views is more important and valuable than delivering views for a longer period of time. I think he right on here, even if I believe his football league is going to fail. (via Blog Maverick)
• Worse Than Failure has been running an unusual contest to get the most interesting, buggy, and unusual way of writing a calculator application. They have 12 finalists for readers to review. I find that the descriptions of how the programs work (or don't) to be hilarious.
• As I have been working on service-oriented management and monitoring I have given a lot of thought to the best way to present the data. Doesn't it make the most sense to primarily display information from the business process point of view? I would be interested in your feedback.

Based on some conversations I have with coworkers over the past several weeks, plus some time thinking on my own I am not sure SOA is the dramatic revolution that it is claimed to be.

I realize that there are numerous definitions for what SOA is, from every IT pundit, as well as many of the big software vendors, but are we really making a dramatic leap? It seems like baby steps are being taken in most cases.

That isn't necessarily a bad thing though. I believe that as parts of legacy applications are broken off or even as interfaces are exposed to allow for common messaging that we are gradually working toward a true SOA evolution. Joe McKendrick writes that many companies have what he calls an Agglomeration of Services (AOS) instead of a true Service-Oriented Architecture (SOA). I agree with him, but ask if that is terrible? It seems to me that at least companies are starting to think in terms of services. Once the value starts to be seen then it is a smaller leap to go from AOS to SOA over going from legacy applications to SOA. So while an AOS isn't nearly as efficient as a true SOA it still gets enterprises moving in the right direction.

I think that Joe does a great job in breaking down the differences quite well. One thing that really strikes me is that he calls AOS reactive and SOA proactive. In my experience this describes many enterprises quite accurately. The problem with being proactive is that the ROI isn't there immediately. That is why in my opinion a true SOA will never get built as a part of a business project, but instead must be centrally funded as an IT infrastructure initiative. In that way the business can continue onward and IT can build out a SOA using best practices and show the ROI that way.

I don't know how many IT professionals read this blog, but I am curious if you have seen companies approach this differently. If so I would like to hear about it, because if I am wrong I would like to know.

I find it interesting how often, even in a technologically advanced company like Microsoft we get so attached to certain tools that we shoehorn them to work in other cases where really a new tool would work better. As a former operations person I understand that it is often easier to have fewer tools rather than more, but I have often noticed that by trying to limit the number of tools we have we actually hamstring ourselves by accepting reduced functionality.

I think it is important to keep in mind what the purposes of tools are:

1. Make jobs easier that we can't do as easily ourselves.
2. Make it possible to do things we can't do ourselves.

If the above two points are true then what is more important than the number of tools we have is that we have the right tool. This became quite apparent to me recently when I was replacing our bathroom sink. I have a few wrenches and pliers, but in order to get to the nuts that were holding the sink in I had to get a special sink wrench. If a tool isn't making our job easier or even possible then we need to modify our tool or create a new tool that will accomplish our task.

Of course what makes IT so much fun is that it can be difficult sometimes to incorporate a new tool without breaking old ones. We also need to ensure that if a tool is really designed to replace an old one we make sure the old one actually gets retired. It is funny how often you get a team where half use the new tool and half use the old one. That makes it difficult to teach to new people and creates an interesting documentation experience. So in conclusion don't get too attached to your tools, and use the right tool for the job.

Joe McKendrick writes an interesting post about if SOA is simply Software as a Service (SAAS) delivered internally. He makes some interesting points and while there are certainly parallels I think that ultimately they are different. Consider the following:

SOA - Two of the key benefits advertised by Service-Oriented Architecture are agility and reusability. In the past I have written that I don't buy the reuse argument at all, and think that mainly reusability benefits exist mostly in the infrastructure capabilities (monitoring, deployment, etc.) So if you discount the reuse argument then the key benefit of SOA becomes agility. The agility of services seems to actually be valid for two reasons:

1. SOA has caused the adoption of several standards for interfaces. Since many applications now support XML based messages for example integration becomes a much easier task.
2. SOA also focuses on business processes. This encourages businesses to break off individual capabilities that need to evolve rapidly to support changing business drivers. This is where SAAS comes in.

SAAS - The benefit of SAAS is that businesses can can use services developed and maintained by an outside vendor. Reusability actually works here because the provider of the service can solicit for customers much like any software vendor does. It seems to me this helps reduce costs for the customer since they don't have to bear the development cost themselves, but at the cost of agility. Since initially a SAAS vendor will have fewer customers they should be more responsive to change requests. Like all vendors though as the number of users grow their ability to react is slower. It is true of course that they can and must support multiple versions of their service, but this also increases the cost of providing the service lowering the value proposition for the customers.

So if SOA isn't highly reusable, which is the key benefit of SAAS, than SOA can't possibly be SAAS delivered internally.

Queue up cheesy Don Johnson video here. What can I say, I was a teenager in the 80's.

As a part of a project I am working on I have been writing some guidance for service monitoring. One of the most basic components of monitoring is of course a heartbeat transaction. Of course a heartbeat by itself isn't really an interesting transaction. At the most basic level it will simply tell us that any remote services our service is using are responding to a very simple request response transaction much like a network ping. What makes this interesting to me is combining a heartbeat with other capabilities. Consider the following:

Service Discovery

Now generally a heartbeat transaction is configured to only ping other services in some sort of a configuration file. What if we did this via service discovery though through something like UDDI? Now this becomes quite interesting to me. Think of the additional functionality that can be opened up if you get a heartbeat to use UDDI instead of a configuration file.

• Adding Service Instances - If we decide that we need to add an additional instance of a credit check service for example it becomes quite easy to do so automatically without worrying that we forget to update calling services and applications with new configuration data. That way our heartbeat can detect a new instance of a service and automatically start monitoring it.
• Load Balancing - One piece of information that a heartbeat can provide is response time. Now it is true that this information is a bit limited since we don't know slow response is due to the network, resource utilization on the server, or the service itself. Even so if the monitoring started seeing slow response time from one of the service instances than we could allow the system to reduce or stop sending traffic to the slow one while diagnostic and repair operations were underway.

Service Provisioning

If we build upon using automatic service discovery with a heartbeat we open up even further possibilities. If a new instance of a service or a completely new service gets registered with the service repository our current service can then make an automated request to get provisioned to start using this service. I admit that this scenario is much more likely with a new instance of an existing service, but depending on how the contracts are designed between services it may be possible to get a current service to detect, provision, use, and monitor the new service without manual configuration changes.

Problem Detection and Repair

One of the real items I am excited about is the opportunity to automatically detect a problem via the heartbeat transaction and then enabling to have the monitoring system start attempting to diagnose and repair the problem. This is one of the best features I like in Operations Manager 2007. You can take alerts from the system and have it run automated scripts to detect and hopefully repair the problem. At the very minimum the data that is gathered by the system should help an operations or test person to have some useful information about what caused the issue. This should dramatically reduce downtime since the basic troubleshooting is done prior to anyone being notified.

Conclusion

While most people consider a heartbeat to be very low level monitoring I believe that there is great power in it, especially as it is combined with other services. As we continue to build distributed architectures SOA being the most current example it is obvious that each service in the architecture needs the ability to check both upstream and downstream services to ensure they are up and available to send and receive messages.

If you spend any time looking at vendor websites from IBM, Tibco, BEA, and even Microsoft it seems like SOA is a product offering you can only purchase from them. Now what makes this really funny, besides SOA being technology agnostic of course, is that their own products aren't SOA at all, but in most cases simply applications that have been repackaged with some SOA branding. At the best case a vendor might provide tools that help you get to Service-Orientation. There products aren't SOA in and of themselves.

Back in point 1 I discussed how a proper SOA must meet the needs and objectives of the business. This means that it is far more likely that in order to execute on service-orientation you will have a mix of different hardware and software vendors in your environment. Contrary to the hype you can have a perfectly valid, well-running SOA infrastructure with competing vendors in it. Yesterday my post was about migrating to SOA while continuing to support the legacy products in the company. This very point means that the framework of SOA must be flexible, because you won't be able to immediately eliminate various disparate applications supporting the business. In fact since the benefit of SOA is to get distributed services each solving a specific business problem it seems to me that the hard or software they run on become even less critical than it is in legacy systems.

I would like to clarify though that I do believe in standards. If you are able to get the majority of your applications and services onto a hardware or database platform the company should start to see reduced support costs, plus increased resource flexibility which is a principle I believe in deeply. At the same time though since the purpose of an IT organization is to make it easier for the business to function it is also paramount to understand what the costs of benefits of specific vendor offerings are before rejecting them for being "non-standard."

In order to make SOA successful in a company we must get beyond the vendor hype. SOA is not, and will never be a product. It is a way of thinking about your business and a methodology to focus on solving business problems. I would ask any vendor who offered to sell me "SOA In The Box" how their offering helps me solve the problems specific to my business.

I have to admit that this seems to be more of a book problem, rather than one that companies are really dealing with. What I mean by that is that the majority of SOA books act as if your CIO woke up one day and decided that the company would develop a SOA system from scratch with no regard to legacy applications and infrastructure. The point is that a SOA will not replace legacy applications overnight and as a part of a well thought out design plan, support for legacy applications must be included.

There is an additional point that should be covered here as well. When the cost of implementing a SOA solution is considered the architect must look at what vendor products are used in the infrastructure. While most companies will have a mix of Windows, Linux, and Unix servers and SQL Server and Oracle databases these items need to play into the design decisions. Of course there can be compelling reasons to chose a different technology than is being used at the moment, but the real costs of making the switch need serious consideration. Those costs will included ramp-up times for the development, operations, and customers of course, plus required changes to support the new applications and hardware. There are also "political" costs of course and often times these can be much higher than one would expect.

One area that seems to get minimized when a SOA implementation is how monitoring and event tracking will change. It is important to consider that most monitoring solutions (operational and business) are based on a standard client/server design. This paradigm changes greatly when you start dealing with distributed services. Since one of the principles of SOA deals with loosely coupled services event tracking will need to be planned out as well. In a traditional middleware solution the state of a transaction is easily maintained, generally in one central database. As we move to more distributed systems where will this data be stored? There are many good solutions, but as above the design needs to account for handling monitoring across both legacy systems and new services that are created.

A point I try and make pretty often when discussing SOA is that the Return on Investment (ROI) has to be over the long-term, because in the short-term costs will go up. In the infancy of SOA in a company there will be many times that there are multiple systems running, both the legacy applications, and the new services replacing them. Make sure this is clearly communicated so that expectations are set, otherwise SOA can easily be seen as a failure since the cost benefits won't be realized immediately.

In conclusion just keep in mind that no matter how cool or efficient SOA technology is that we have our primary obligation of keeping the lights on and the doors open while we transition to the new technology. As my coworker Harry writes, we don't need to take oaths or sign affidavits to make this happen. It should be an ingrained part of doing our jobs.

I find it interesting how SOA gets pigeonholed as a certain technology or architecture that must look a certain way in order to be considered proper. In my first point of SOA, I point out that SOA must meet the needs and objectives of the business. This comes down to the framework. If you look at different companies each of their implementations should look quite different depending on how their business, what legacy applications they still need to utilize, what the direction of their future plans are, and what kind of culture they have in the company.

John Evdemon is an architect here at Microsoft who's opinion I respect quite a lot states that defining a proper SOA is like "nailing jello to a wall." I guess I will need more nails. I tend to think that my ideas are mainly principles that support my first point. The key element is that the SOA implementation of a company like Amazon should and does look quite different than one that a company like at&t, Boeing, or Premera Blue Cross would implement. To an outside observer Amazon might look just like a bunch of web services, but what do I care as long as I am able to find and order the latest John Grisham or Michael Crighton book without having to think about the technology.

The key is that SOA is a framework. Like all frameworks service-orientation must be strong in certain areas (helping business, governance), and flexible in others (technology, message protocol). SOA is flexible though, and if you want to evaluate its success in a company just look at the following items:

• Is the technology making it easier to do business?
• Can the SOA easily be adjusted to new and changing business needs?
• Is the technology transparent to the users?
• Are we seen as a help or a hindrance?

If the answer is yes to the first 3 questions, and as a help to the last I think we can say the SOA implementation is a success and is a "proper SOA."

When we look at IT do we give consideration as to what our purpose is? It is not to play with the latest gadgets, or to develop the coolest tools. Our purpose ultimately is to help the business succeed, not just in the current market, but also to provide a framework that allows our company to respond as quickly as possible to changing market conditions. This is the true value add of a Service-Oriented Architecture.

So when we evaluate our success in implementing an enterprise SOA we need to measure success by the benefit to the business. Joel Dehlin, the CIO of the Church of Jesus Christ of Latter-Day Saints writes an interesting blog today on how Performance=Results. This really is the key. We can use the newest state of the art tools but are we making it easier, cheaper, faster for the business to be successful.

Bill Gates wrote a book entitled Business @ the Speed of Thought. This is what the real benefit of SOA is. Of course even in a well-designed SOA we aren't able to adjust to changing business conditions at the real speed we need, but much faster than in previous iterations of software. The point is that the quicker we respond to changing needs, the farther ahead we are of our competitors. That is a real tangible competitive advantage.

The other part of flexibility is core to the idea behind SOA. The point is that each service represents one business process. That way we can also make changes to individual business processes with limited impacts on other services in our system. In my experience analyzing the impacts and changes required to all downstream systems and modifying them introduces the most delays to getting changes delivered.

What this means is that in order to be productive and benefit the business we need to partner more closely with them, and understand what is trying to be accomplished. That way we can truly be seen as a key contributor to business success.

"Discipline is the bridge between goals and accomplishments." - Jim Rohn

One of the main benefits of SOA according to Thomas Erl and others is the reusability of services. Now, as I have written before I believe reuse is not any more likely to exist in SOA than it was in the preceding technologies that have come before. I will say though that if you are going to get any reuse benefits, or refactoring ones as my coworker Harry writes about you will have to take a very disciplined approach to the development and architecture of services.

I do believe that agility is the key benefit of SOA. In order to achieve  agility in a real way though , there must be a governance process to encourage the various teams contributing to a SOA project to use common methodologies, communication protocols, message formats, and technology where it makes sense to get the best return on investment for the company.

Governance becomes incredibly critical when you are dealing with multiple teams contributing to an enterprise wide SOA initiative. It is the nature of IT professionals to be mistrustful of code developed outside of their organization. This is where governance can provide a tremendous benefit. Please bear in mind I am not endorsing a stick approach to governance, mandating that work must be done in a certain way. On my team we talk about helping people fall into the pit of success. This means that a smart governance team must look for ways to make it easier for the various contributors on a project to choose the right path rather than governing by executive order. There is a really good George W. Bush joke somewhere there I am sure.

It is also smart to be disciplined as you approach SOA. Like any new process it is almost certain that mistakes will be made along the way to implementation. By taking a disciplined approach those mistakes can be minimized, and more importantly they can be recovered from more quickly. I think that much like it is with raising childen, discipline is difficult at first, governance is seen as an obstacle to success, but as we get in the practice of following the principles it becomes a habit, and is a part of our nature.

I freely admit that I am a techie to the core. I love gadgets, and always want to see the newest coolest invention that will make my life easier. In some ways this seems to be a requirement to work in IT. Working at Microsoft sometimes seems like being a kid in a candy store with all of the great technologies and tools being developed. In many ways though this mentality creates one of the biggest obstacles in getting a proper Service-Oriented Architecture designed and deployed.

During my time working in IT I have attended numerous meetings with the purpose of discussing a business problem that has been brought to IT to solve. Much of the time the discussion quickly devolves into an argument about what technologies to use and the original business problem gets dropped on the floor. Of course it is the nature of IT professionals to want to use the latest greatest technologies available because many of us enjoy living on the bleeding edge with our gadgets, our computers, our software, etc. It seems to me though that if we aren't careful we neglect the purpose for which we all work, which is to help the business to succeed.

Of course this works the other way as well where a vendor has convinced management to purchase a certain brand of servers, databases, or application suites, and only that brand can be used to solve the problems of the business. This doesn't lead to a good solution as well since each vendor has strengths and weaknesses in their products. Often times the strengths don't provide value to the problems being solved, and the weaknesses are in areas that actually hurt the business.

In my mind these two issues are what have caused some of the failures that the industry has seen in enterprise SOA implementations. Now that where architects need to come in. It is paramount to our jobs that we ensure we understand exactly what problem(s) the business is trying to solve, what their needs are, and that we analyze how to best meet those needs and choose technology that best solves the business problem while being able to interface with our current tools, applications, and services. There will be trade offs along the way, but it is critical that as architects we don't lose sight of the main goal which is to solve business problems so that they can succeed.

I put this item as the number 1 goal of a proper SOA because if we don't design something that meets the needs of the business nothing else will matter. Our design will be a failure and we won't be seen as a partner to moving the business forward, but as an obstacle to success. I want to seen as a successful partner, not an obstacle, especially when budget time comes.

As Service-Oriented Architecture continues to spread through the IT industry I find it interesting on what constitutes a proper versus and improper SOA implementation. This is an compelling question because it seems that anytime a SOA deployment fails it is because it isn't a proper SOA in the first place. Since it seems that we like to define SOA by what it isn't, I thought I would take the opposite tack and define what I believe constitutes a proper SOA. As always, I am interested in feedback, as I will be the first to admit I don't know everything.

A proper SOA...

1. meets the needs and objectives of the business.
2. requires discipline and governance to manage.
3. provides agility to quickly respond to changing business drivers.
4. is a framework meaning the specific implementation will be different from company to company.
5. must work with your current infrastructure while legacy applications are being migrated to services.
6. is flexible enough to support multiple vendors, software, and hardware.

I am sure there are some more areas I haven't considered yet. Over the next few days I am going to try and come back to expand on each of these areas, because I believe it is important to understand what SOA is, rather then what it is not.

In an effort to work on reducing my swearing I have decided that instead of referring to clueless SOA evangelists and architects as Service Oriented A-Holes I will use the term SOAholics instead. Much like the original Alcoholics Anonymous* there are 12 steps to recovery from being a SOAholic. First though you must determine if you are a SOAholic, before you can get on the road to recovery.

Signs You May Be A SOAholic

• Your designs only work well on a whiteboard or in a Visio drawing.
• Service reuse is the key benefit of Service-Oriented Architecture.
• Political obstacles to SOA implementation are best overcome via CIO mandates.
• Service governance is an optional part of your SOA design.
• The framework is more important than the business drivers.
• A poorly working production implementation is the result of lazy developers and operations administrators, not your design.
• No one else understands "proper" SOA other than you.
• You lecture or write about Service-Orientation without ever having implemented in production.
• A random collection of web services is a good SOA design.
• You don't believe your current production applications need to continue to function while you design a perfect SOA solution.

Recovering from SOAholicism

1. We admitted we were powerless over whiteboarding-our architecture had become unmanageable.
2. Came to believe that a framework greater than ourselves could restore us to sanity.
3. Made a decision to turn our will and lives over to the care of architects that understood the business drivers and customer needs.
4. Made a searching and fearless technology inventory of ourselves.
5. Admitted to management, to peers, to customers, and to ourselves the exact nature of our Service-Oriented mistakes.
6. Were entirely ready to have grounded architects remove all of our design defects and bring us back to architectural reality.
7. Humbly asked senior architects to give feedback on our design shortcomings.
8. Made a list of all of the customers and projects we had harmed, and became willing to make amends to them.
9. Made direct amends to our customers wherever possible, except when to do so would injure the system or business more.
10. Continued to take a personal inventory of our Service-Oriented Architectures and when we were wrong promptly admitted it.
11. Sought through questioning and listening to understand the needs of the business and work with our partner organizations to ensure our designs are realistic in an enterprise operational environment.
12. Having had a technological awakening as the result of these steps, we tried to to carry this message to other SOAholics, and to practice these principles in all of our affairs.

* This post is in no way intended to make light of those suffering from alcoholism. If you are an alcoholic, I hope you will seek out help, it doesn't have to be AA, as there are a number of worthy organizations that can help you.

As my team works to design and implement service orientation internally it seems like we keep running into Service Oriented A-Holes as we architect.

Definition: Any person or team that pontificates on Service-Oriented Architecture (SOA) without considering the realities of implementing SOA in a real business environment with real suppliers, customers, and products. These people are great at designing something on a white board or on paper, but couldn't produce a real workable production ready system if their life depended on it.

You might think that this could apply to any architect working on SOA, but it doesn't for the following reasons:

1) Most of the architects I work with, myself included, try to consider carefully that the way something works on a white board isn't always (often) the way it will work in production.

2) While speakers at SOA conferences gloss over or ignore this point it is critical to consider political and operational realities when designing a new solution. This includes the sad reality that the system has to continue to function while SOA is implemented and we don't get to "start from scratch." Real architects understand that systems aren't designed and implemented in a vacuum.

3) The carrot is a much better way to direct behavioral change than the stick. It continually amazes me that anyone would think that a CEO, CIO, etc. can simply mandate a radical behavior shift without having to sell the change to key people and teams. Just like any product, real world architects know that the benefits must be "sold" to the customer, not foisted upon them.

4) In most cases the advertised benefits of SOA aren't the same as the actual benefits. I won't go on a reuse rant here, but feel strongly that reuse is the most over-hyped and under delivered perceived benefit of SOA. What makes this particularly sad is that reuse is the "Holy Grail" of most new IT initiatives. What needs to happen to prevent SOA from being seen as a failure is to communicate the real advantages to the decision makers. These benefits will depend on the audience, but the ability to quickly respond to changing business requirements seems to be the most realistic reason to implement SOA. Reuse, if it occurs, is at best a secondary benefit.

Most of the Service Oriented A-Holes work the industry conference circuit and write the books about SOA it seems. That's why another member of our team and I would like to write a book about the reality of implementing SOA with all of the warts and lessons learned. That way a more realistic view of what it takes to implement would be out in the world for people to see, and then decisions could be made based on real benefits and costs.