And Why It Matters
Written by Steve Weber
Imagine real estate buyers assessing the potential of an investment property. “Well, it might need updating, but it’s got great bones!” The interior is probably 70’s goldenrod and pea soup green, but that doesn’t matter. They can strip the building back to its framing and update it with a modern twist. In most cases, they can save what they like from the old and swap what they don’t for the new.
Unfortunately, software isn’t like that. Most enterprise software today has architecture from the 1990s or even earlier, and this isn’t just true of software purchased back then. Occasionally, software recently purchased might be built on a 1990s architecture. Unless the buyer is tech-savvy, they may not know.
So why does this matter? Software architectures have dramatically changed in the last 10 years, providing greater reliability, flexibility, and customization. But you can’t gain those benefits by retrofitting new APIs onto old software. This is what you need to know.
Old software is too rigid for today’s innovation
In the 1990s, software systems couldn’t connect to each other except through herculean programming efforts. In those days, companies bought monolithic enterprise software packages from SAP, Peoplesoft, and Oracle to run their business. These projects famously went on forever and often failed.
The software model today has evolved to look a lot more like how construction companies operate. They assemble a team of employees and subcontractors, each focused on their specialty to deliver a flexible structure. No one, not even tract home builders, self-perform all the work, but most construction companies still use software that tries (and fails) to do it all alone. This just hinders innovation.
Why is modern software architecture different?
Today’s software allows greater flexibility and customization. It builds on a series of tools and services that operate together to execute an integrated finished product. Think of the most important components like the elements of a building.
Open API—The Steel Framing
An Application Programmers Interface (API) provides connectivity and integrity, ensuring that your software “building” can work safely. Every module, from billing to project management, uses an API to exchange information with the database, other modules, and external programs. It maintains all the business rules that ensure your software has accurate information. It won’t let you accidentally date an invoice with the wrong year, for example.
Now this hasn’t always been the case. In the 90s, the API was not a structural element but sat alongside the software. It couldn’t enforce business rules. Therefore, software vendors limited access to the API because improper use could corrupt the accounting system’s data.
The API is called “open” for two reasons:
- It’s based on open API standards
- It’s publicly documented so that any third party can create connected applications
This is a sign of really good software architecture.
Big companies publish their APIs to encourage third-party developers (like PaperTrl) to write add-ons. This gives companies more choices to custom-design their software. These open APIs can also act as building inspectors, ensuring everyone obeys the rules and information flows smoothly so that add-on components behave like part of the original software.
That’s why it’s crucial to invest in modern software. Just as it might be cost-prohibitive to swap out an entire building’s post and beam construction for a steel frame, you can’t retrofit an API onto 1990s software.
Microservice architecture—The Building Interior
Microservice architecture separates all the components of a piece of software. For instance, invoicing is separated from banking which is separated from project management. In the old days, these functions would have been hardwired together like an interior structure tied to load-bearing walls. You couldn’t change one without causing problems with the rest.
Microservice architecture allows each component to operate independently. For users, this means better performance and reliability—gone are the days of a single point of failure. You can customize components, swap them out, or drop them as your business needs change.
Open Authorization Security (OAuth) and User Roles—Building Security
Like modern badge readers for humans, OAuth grants access to pieces of a software’s components based on their role. However, OAuth goes one step further.
You wouldn’t set up a multi-building campus with separate card reader technology in each building, requiring each employee to carry multiple badges. And you don’t want the same for software administration. OAuth allows a company to standardize management of usernames and passwords across their various software systems, leaving it to trusted authorities like Microsoft and Google to worry about user account and password administration.
Companies can focus on defining which features and data that user (or role) can access within the software using OAuth. Imagine it like hotel logistics:
- “Guest” is one hotel role. Every guest can use their key card to enter the building after hours, access the swimming pool, and enter their own room. However, they cannot access the hotel’s business office or steal extra mints from housekeeping. This is your average construction employee.
- Hotel employees have a different role. They can access most parts of the hotel and some, like housekeeping, can even access guest rooms when necessary. This role is like your construction managers or department heads.
- The hotel designates these different roles and doesn’t have to define this access each time they issue a key to a guest—it happens automatically with each guest sign-in. The only thing unique to that guest is which room that card can access. This is the power that C-suite or administration has.
Likewise, the combination of OAuth and roles is used to grant access to the system and third-party add-on software. When this type of security is embedded into the application, it guards against potential hacking, data corruption, and security breaches.
User Configurability—The Building’s Interior Layout and Design
Just like modular components have transformed how inhabitants can customize their interior spaces, software configurability allows architecture customization. Users can add extra fields to a screen to capture additional information or create workflows that automatically route transactions for approvals without needing massive renovations.
While the concept of user configurability has been around for a long time, many software companies didn’t have a suitable methodology for managing these configurations. Each upgrade required a separate scope of work to ensure that all its customizations would survive the update.
Modern software expects these configurations and allows the user more direct control to make the necessary changes
- The API has been programmed to expect new fields
- The OAuth security system is configured to ensure security and integrity as users navigate the system and make changes
This prevents a user from accidentally knocking down a load-bearing wall in the software architecture.
App Store—The Home Depot
Third-party add-ons can now be as safe and reliable as the core software application, thanks to the above elements. They enable customers to consider a “best of breed” strategy when selecting software for their business rather than being locked into one single piece of software.
Modern software stacks focus on a “best of breed” configurability, which is great for companies in all industries:
- Third-party developers can build industry-specific components to tailor the software to one segment–think software for a home builder versus an electric contractor instead of general “construction.”
- Software vendors here set a high bar for participation unlike your cell phone app store–They often require apps to have several customer references and undergo third-party testing before being accepted in the app store.
- The app stores allow end users to rate and review the software using raw, unfiltered feedback on the product–The user community often swiftly notes missteps here, and the best vendors organically float to the top.
Building software that works for you
In a recent post, Forrester, a large software research and consulting firm that helps companies evaluate and evolve through technology, wrote:
“Rather than single-sourcing an (enterprise software platform), think about your (enterprise software platform) as being:
- A system of applications (and their underlying platforms) …
- … brought together by various vendors and agencies …
- … bound by APIs and events …
- … connected through good data …
- … provides the foundation for experiences and apps to be rapidly built on top …
- … and charts the course to front-/back-office unity under an experience architecture.”
Sounds a lot like construction, doesn’t it?
Unfortunately, Googling a vendor and their software typically doesn’t provide great results. Software vendors do not publish “born on” dates on their websites and identifying the underlying architecture can be difficult without a trained eye. Furthermore, software providers like Sage and Microsoft have grown by acquiring other software vendors so the architecture of their offerings vary widely.
To find the right software, consider the following:
- Avoid starting with software resellers.
- Work with an IT services company that offers services in technology consulting, business analysis and project management that can act as general contractor and help with vendor selection.
- Look for software applications that have growing app stores, especially those that have specific add-ons for targeted at construction.
- Beware of software comparison charts or review sites that only focus on features without regard for architecture.
Technology plays a huge role in the operations of an organization, yet it is often the most underfunded division of construction companies. Invest in finding a good partner to ensure the software you choose is designed in a way that maximizes its effectiveness and ultimately your success.