Making the Cloud, Microservices, and Enterprise IT work!

In the space of Software Architecture, the “Big Ball of Mud” represents “natural growth” – or the system that just adds and changes without ANY planned architecture.  ( More on the Big Ball of Mud here .)  While we hear about it, and sometimes run into it as we have to solve project problems, how do you spot a software product in that mode? Side note… while traditionally a Big Ball of Mud is discussing gradual changes to a system or program, we also see a Big Ball of Mud in enterprise architecture in unplanned natural growth of the addition of various systems and technologies, and interfaces and interconnections between them.  While dealing with spaghetti code is tough, dealing with spaghetti connections and systems is extremely expensive and risky – but is all too frequent. Here’s a software product conversation I had this week …   Please wait for a site operator to respond.   You are now chatting with 'Randy'.   Your Issue ID for this chat is LTK1219208815693X

To understand what makes easy integration or a “good web service”, it’s worth taking a glance at the historical methods of I.T. systems integration.  After all, business systems have been passing data around and/or activating each other, aka integrating, for almost as long as there has been commercial I.T. business systems (approximately since 1960).  The first major “interface” method between systems was throwing sequential fixed-length record files at each other.  This was pretty much the only method for 20 years and still remains in widespread use, though mostly around mainframe and legacy systems.  The system providing the interface, either outputting the data or providing a format for which to send it data, defines a field by field interface record, along with header and footer records.  Because these are fixed length records, the descriptive definition (the human readable documentation) must include the format and length of each field, along with any specialized logic interpret