Making the Cloud, Microservices, and Enterprise IT work!

Loriane Lawson over at IT Business Edge has a penchant for touching upon particularly interesting integration problems.  This week she asks … It's interesting: Writing custom code for data integration is nearly universally frowned upon by experts – and yet, I'm seeing a lot of discussion about creating your own metadata solutions for support with integration. My question is: If you're getting away from hand-coding, why would you want to delve into customized metadata solutions? The article focuses upon some of the technical issues and technical approach to such a discussion.  I’d like to focus on the business issues, and how those should be directing the technical approach (but aren’t). Every application involved in integration brings along it’s database (or general data) model and it’s internal data object model.  These models were developed to meet the functional goals of the particular application.  For example, the “customer” representation in t...

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

Jim Sinur at the Gartner Blog Network notes that Application Package Vendors and BPM Vendors are beginning to encroach on each other's territory. How so? Package Vendors are beginning to incorporate some level of process control, and exposing the fact that they have tremendous vertical market expertise in the business processes incorporated into the application (exposing as SOA services and exposing as marketing). Who better than a vendor that's been creating CRM software for 20 years to understand the automation of CRM business processes? BPM vendors are beginning to accumulate some significant libraries of business processes. As such, they're beginning to arrive with "industry kits" that contain common process sets for specific vertical markets - turning the BPM system into a partial package application for that industry. Further enhancing this is BPM's primary focus at allowing easy adjustments to the process - equivalent to complete customization of t...

My wife sat next to my 9 year old daughter sharing a moment of watching a video on Youtube. My daughter watched, came to a part that she didn't enjoy as much and slid the play-slider up to another part. My wife responded by saying "that's really annoying, you learned that from your older sister." I paused her and explained that for my daughter, media is an on-demand experience. Pick what you want, watch it, skip parts you don't want, rewatch parts you particularly enjoy, and share it with friends & family with a click. Whereas my and my wife's experience is broadcast media. You watch (or listen) to what comes on, watch it from beginning to end, and if you missed it - oh well. We don't interact with or adjust our watching experience - she does. (I've actually been in the car with the radio on and had my children say "could you pause it and put that back, I didn't catch what he said".) Clearly for those in the media business this poses ...