These days whenever a developer writes a single line of code, it is very critical that he understands the dependencies between business and the underlying technologies. Neglecting the business context can result in a project in which SOA infrastructure is pursued for its own sake, or where investments are made that do not line up well with the needs and priorities of the business. Todays enterprise developers should be thinking "SOA". Everything should be services.

 

For developers working with the Microsoft technology stack, using .NET, BizTalk, IIS etc. we have everything we need to create sophisticated distributed applications. However, there are a lot of moving parts. Most of us now work in heterogenous environments, where distributed applications span a variety of technologies, and possibly business partners and customers.

 

It takes a lot of skill to blend all the pieces into a cohesive whole and it takes time. SOA is not a product, it is a way of thinking about software development. When faced with a functional requirement, think how that can be decomposed into a set of services. When done properly these services will not only solve the current requirements, but will

also be the building blocks that can be aggregrated to meet future needs. 

 

Microsoft's stack of technologies ( WS*- specs, BizTalk Server R2, WCF,

WF, WPF ... have the potential to improve our productivity and agility.