Making the Cloud, Microservices, and Enterprise IT work!

Suddenly this year clients are calling me up about SOA Governance, service libraries, service monitoring and control.  First SOA was dead, then SOA governance was dead (even saw an article that SOA governance is more than just dead, it’s a murderer, killing the future by stopping cloud computing).  What’s going on with all my customer calls? Here’s a simple fact about services.  Until a significant percentage of frequently used business processes have been exposed, and exposed at a relatively granular (detailed) level (without being too granular that they require re-composition and orchestration every use), the major SOA ROI (return on investment) doesn’t happen.  Kind of like a real world physical library, it won’t have much traffic until either it has a large collection or a collection of popular material. Most SOA efforts begin Bottom Up, with programmers and projects beginning to use SOA technologies simply because they are available and enable getting...

Bridging tools allow a communications protocol or methodology change. Generally bridging tools are unique one-off solutions and need to be avoided in a SOA integration environment. There will be some instances where only a bridging tool will do, those are when basically the only way to connect or bridge is via that tool. The general rule is reduce bridging tools to the minimum set needed, and use the more generic SOA bus tools to replace them with a single tool or a suite. Why? Bridging tools usually require their own environment (their own server or region) and have specialized configuration parameters and settings. Supporting them is supporting another complete application and technology. But because they are narrow use, the knowledge to support them is usually concentrated within a small group (often just 1 or 2 people). Often a variety of bridging tools are being used in an enterprise as they were brought in over time to make connections that only they could make...at that time...

Twenty five years ago my boss handed me the primary billing program and described a series of new features needed. The program was about 4 years old and had been worked on by 5 different programmers. It had an original design model, but between all the modifications, bug fixes, patches and quick new features thrown in, the original design pattern was impossible to discern. Any pattern was impossible to discern. It had become, to quote what’s titled the most common architecture pattern of today, ‘a big ball of mud’. After studying the program for several days, I informed my boss the program was untouchable. The effort to make anything more than a minor adjustment carried such a risk, as the impact could only be guessed at, that it was easier and less risky to rewrite it from scratch. If they had considered the future impact, they never would have let a key program degenerate that way. They would have invested the extra effort to maintain it’s design, document it property, and consider ...

While IT analysts and pundits are busy declaring SOA is dead, SOA has failed, and the downturn killed SOA, the hype of 2009 is Cloud Computing and the resurgence of Software as a Service (SaaS). ( Microsoft Azure being a prime example.) In my discussions with my corporate clients, as well as from my own extensive corporate history, I'm finding that allowing key corporate data and processes to leave the walls of the company controlled data center is the main mental barrier to SaaS and Cloud Computing. Even though companies are outsourcing business processes and the associated data that goes with them - as well as outsourcing some applications to hosting providers - the thought of deploying their applications to an amorphous cloud and depending upon the vendor to just "support and provision it appropriately" is a mental leap they're not yet prepared to make. Similarly, relying upon services that a vendor will just "support and provision appropriately" is a...

Why is a Cisco router $10,000 and a Linksys router $100? Or perhaps the better question is why are your network guys willing to pay $10,000 for a Cisco router when a Linksys router can be purchased for $100? The answer is that Cisco routers have multiple layers of reliablity, managability, and security that Linksys routers don't. But 100x (100 times) difference? Is it really worth 100 times difference? The network is the backbone of your IT infrastructure. If your network goes down, all the IT systems stop working and so does much (if not all) of your company's operations. And keeping that up, being alerted early to problems, being able to reroute and resolve problems, that is indeed worth 100 times difference. When creating traditional big-box applications, the traditional components are: The Application You Wrote The Container or Runtime The Application Server The Database The Database Server (When we move to an application with a web GUI, you can add a web server in ther...