From the Inside September/October 2015
How do you build a new business application using all the current technologies and design patterns? I've been thinking about this for a while now. So, I've decided to take on the task of reinventing the wheel.
Why do this? There are tons of applications out there that already do accounting, inventory, manufacturing, and/or service related offerings. Why put any effort into recreating all that work?
My main reason is because it feels like no one has really tried recently. There are lot of "bolt-on" applications that are designed to work with existing LOB (Line-of-Business) software and existing accounting applications. I've even seen some open source applications out there that tried to tackle this sort of fresh approach, but they are designed narrowly, to solve a specific interface task more so than to reap the advantages of current technology and design practices. These applications work well for what they are, but stop short of what businesses will need to meet future requirements.
So, for better or worse, I'm starting an article series that goes through the practice of building an accounting application using the "API" or "Micro Services" design approach.
Since most you already have an existing, well used, and hopefully well loved, LOB application running your company, I hope you will be inspired by these articles, sessions, and code samples that will show different ways to solve the problems associated with building the next generation of LOB applications.
Spectrum published a series of articles on Inventory Management < http://intl-spectrum.com/mag/MARAPR.2006/default.aspx > some years back. Those articles asked us to re-examine that part of the business. This series will do something similar for accounting.
So for starters, what are some of the things the next generation of LOB software must have?
API and Micro Services
APIs are simple, modular routines that are designed to access specific business processes. Sometimes, APIs are just data access, but many times the APIs are accessing other APIs to do more complex tasks. We already do this, often without realizing it, when creating MultiValue BASIC subroutines.
So, APIs are those individual "access/end points" into an application that do specific functions like: Post GL, Reverse GL, Update Inventory Running Totals, Read Customer Information, and so on. Micro Services are a new concept that puts a shell around the API application development, creating an interchangeable application structure. I'll get into Micro Services and their designs later in the series.
Adaptive Interfaces for Users
Every user is different, and every user interfaces with the company in different ways. I'm not saying that every API has to be available from every interface, but a failure to adapt to different interfaces is a shortcoming of many LOB applications. Our new LOB APIs must be workable from any interface that the user has access to, within reason.
If the user wants to input data using Excel, then provide them with an interface that allows them to create, retrieve, and update from Excel. If they need mobile access, then provide a rich mobile interface. If you have a customer facing website, then provide real-time, secure interfaces to customer data. For the users that work at their desk all day, provide them a desktop application. If you have a user that just needs a dashboard, then provide them a dashboard.
You get the point. Allow the user to define how they interact with the API, never allow the API define what interfaces the user can access.
Reporting, Smart Data, and Business Intelligence
It doesn't do an application any good to store information but never do anything with it. Unfortunately, a lot of LOB applications do exactly that. They provide some BI and some reporting, but nothing really good in the way of interfaces to create Smart Data .
Interfacing with Data Lakes , Shared Data systems , or Big Data is a must for any LOB, even if there isn't a pre-identified need. Restricting yourself to just looking at the data you've collected can become a business trap, so pulling in data from other locations to enhance the information you already have is a must. Even if it is something as simple as combining what you have with data drawn from Social Media.
Interfacing with Outside Systems
Okay, this may sound like a repeat of the two above, but it is really important in its own right. B2B sources aren't just useful for the data you can import. Exchanging information with the same B2B sources is equally as important. How many times have you had to interface with other systems through some kludgy methodology to get the simplest piece of information? EDI comes to mind.
There are tons of web services out there that can process or manipulate our data better than what we can write from scratch in a reasonable amount of time. This means exporting data and importing data is a must, even when the other system has no additional data to offer. Business applications are not just about the data, but also about the business logic for processing that data.
The New Series: Starting Next Issue
I know I'm taking on a substantial task. Whatever input or help that people are willing to provide would be welcome.
