Four Observations from Gartner AADI Summit in Sydney


Rik Chomko


I recently had the pleasure of attending the Gartner Application, Architecture, Development and Integration Summit (AADI for short) in Sydney. It was a well-attended event with a wide variety of IT folks in attendance, such as CIOs to Enterprise Architects to Development Leads to DevOps. Like the Gartner Enterprise Architecture events we sponsored this year in Orlando and London, I came away with some observations worth sharing. A couple of them are at the macro IT industry level and a couple of them are at the micro decision management market level:

  • A one-size platform approach won’t work anymore. According to the attendees I talked to, many were looking to get away from monolithic applications that promise to handle all aspects of their business. Instead, they were looking for best-of-breed vertical and horizontal cloud offerings that could be stitched together via services service buses. The individuals I spoke with were embracing the trend of a multi-cloud since it gives them the flexibility to more quickly swap out for new services and products. Across all of these, it was mentioned that configurability is key. You need to be able to change the behavior and decisions the software without complex coding or scripting.
  • IT is in the same boat as vendors (ISVs) when it comes to getting funding from the business. More and more IT groups are getting evaluated and competing against ISVs on the Features, Functions and Benefits (FFBs) they deliver. In some organizations, it’s no longer assumed that IT and the services they provide will be part of the picture for new initiatives. Internal IT teams are being asked to respond to RFPs in much the same way a vendor would. The best solution, long term maintenance strategy and cost will win.
  • Rule harvesting is a big problem. Rules exist in a lot of forms in the enterprise. Some are hard-coded in legacy systems, some are in stored procedures, some are in documents, some are people’s heads, and some are in a metadata form (like another rule technology’s format). For companies that are staring at one or more large digital transformation projects, one of the hardest parts to understand and estimate is the amount and complexity of logic buried deep in the COBOL, Java, and even VB 6 code. Folks got excited when we had a chance to explain how InRule can help companies staring at this large logic migration effort.
  • Low code solutions don’t do rules well. Low code solutions are great for standing up solutions quickly, especially where there is a heavy workflow and screen interaction component. Assuming the data/entity model is well-organized and thought out, low code solutions are capable of delivering very credible line of business solutions in a short amount of time. However, they tend to fall short when it comes to the modeling and writing of rules. For example, we met an attendee who was familiar with one of the stronger low code vendors and rule technology. He said they are implementing a rather complex set of functionality in the low code tool that included a few thousand rules. The gentleman said it wasn’t going to work if they were going to have to implement all those rules in the scripting component provided by the low code vendor. In his mind, using a Business Rule Management System (BRMS) with the low-code tool was the way to go.