Making the Cloud, Microservices, and Enterprise IT work!

I was impressed with the following online flash game that teaches basic programming concepts. Using the game I was able to get programming concepts across to my children that previously evaded them. Check it out: Light Bot

Governance (service governance, design time governance, run time governance) is not going away. There are some who are under the impression that as the tools become more sophisticated and become integrated into the environments, and as SOA progresses into a realistically deployable cloud computing model, that governance becomes part of the background operation. Todd Biske makes a very convincing argument otherwise ... The ...problem with (this, that governance is going away) statement is the notion that design-time governance is only concerned with service design and development. That’s simply not true. (There are) three timeframes of governance: pre-project, project, and run-time. There’s a lot more that goes on before run-time than design, and these activities still need to be governed. It is true that if you’re leveraging an external provider, you don’t have any need to govern the development practices... Todd has a lot more to say on the matter worth reading. But the point is, e

In existing IT systems, services tend to get created as IT projects require access to a function or bit of data from another system. The need is for a specific narrow bit of functionality or narrow data set. The function the exposing system has internally usually offers a wider bit of functionality or data. Example: System B needs customer data from System A, specifically they need the name and address. System A’s internal customer query function retrieves the customer, name and address, demographic data, and a list of related customer accounts. System B’s project manager comes and says I need the customer name and address, please expose it. System A exposes it, matching exactly what System B needs rather than what System A can actually do. A year later System C needs customer data, plus demographic data. The service needs to be changed to match System C, requiring System B to retest as well. Or alternatively a new service is created. In the first case the testing costs go up, in

The right way to expose functions, creating web services, has nothing to do with technology and everything to do with architecture and the business. The rule is: fine grained business functions are services. The granular level at which the business thinks about business processes is the level at which IT systems should expose web services. Why? Because when your business comes to talk to IT (and even talk amongst themselves), this is the level they talk at. When they reorganize business operations, this is the level they organize at. Therefore, this is the level of agility they expect the IT systems to have. When web services are more coarse grained than this, the services frequently have to be adjusted and redesigned for changes – losing the benefit of reuse (or centralized use / single instance). When services are more fine grained than this, every integration requires significant effort in orchestrating multiple services into the expected business level of functionality, losing