If you backed me into a corner and asked me what’s the toughest and most challenging kind of software development I’ve ever experienced, I’d have to say hands down, it’s the world of enterprise software development.
To be clear, enterprise development is all about solving company-level problems with software automation and custom programming.
Say, for example, you work for a company that sells farm equipment. You’re the sales manager for the company’s sales department, responsible for driving new sales revenue and business to the company.
As the sales arm of the company, you’re usually the first step in a long chain of workflows and business processes that need to happen in order to complete the sales process.
After all, signing a new sales contract is only just the beginning of the whole sales cycle process.
After the customer signs the contract agreement for the purchase of some farm equipment, lots of other things need to happen.
The sales contract needs to end up in the billing/accounting department, so that the new contract can be billed as new incoming revenue.
The sales contract also needs to end up in the manufacturing arm of the company where the actual farm equipment is assembled together, according to what was agreed to on the sales order … maybe the sales order consists of a tractor, a harvest combine and a … fertilizer doohickey? (hey, gimme a break, my knowledge about farming begins and ends pretty much with “Little House on the Prairie”!)
Once the actual farm equipment has been completely assembled and ready to be shipped, then the shipping department needs to be notified so they can figure out the logistics of where and how the customer actually receives their order.
This is, of course, a very simplified and high-level description of something that in reality, is probably much more sophisticated and involved, but you get the picture.
But as you can imagine, there are a lot of things that need to happen, either in parallel, or one process dependent on the completion of a previous process, in order for the entire sales order cycle to properly complete.
But in most B2B or B2C type companies, there are 3 high-level processes that usually take place.
1. A sales order
2. The fulfillment of the sales order
3. The shipment of the sales order
Most companies consist of smaller entities that handle each of these major processes, either in the form of a division, department or some other entity.
And they all need to work together smoothly and efficiently in order to keep their customers happy and increase revenue and sales.
Before the dawn of the computer age, we puny humans had to laboriously keep track of all these processes by hand, usually in the form of big paper trails, contracts, bills, etc.
If there’s one thing that computers excel at, it’s their ability to automate repetitive tasks at speeds, lightyears faster than the level we humans can manually process information.
As computers began to infiltrate society, one of the first places they were put to use, outside of the military and educational institutions, was in big corporations.
People recognized that computers could keep track of all these former paper trails, and forms and processes electronically, at a much faster pace, and save money and increase efficiency over time.
And we lived happily ever after, right??
* cue sad trombone music *
Ideally, you want every computer system from sales, order fulfillment, manufacturing, and shipping departments to seamlessly communicate with each other in a nice, orderly fashion. When the sales order is finalized, it should notify the order fulfillment and manufacturing departments to begin the process of building the farm equipment, based on the specifications of the sales order.
Then once the order fulfillment is complete, it should notify the shipping department that the sales order is ready to be shipped and they can begin the logistics of figuring out how and where to ship the order.
All in a nice, automated workflow where all the appropriate people get notified from each department.
And in a nutshell, that’s exactly what enterprise software development is supposed to do. It’s about connecting all the major business components of a company together, so that it contributes to helping the company create revenue in the most efficient and timely manner possible.
So where is the challenge?
In my experience, the challenge is twofold.
1. Technical debt
2. The silo problem
Technical debt is what happens when you stop paying attention to the code base and architecture of an application or system.
It’s sort of like what happens when you neglect to maintain your car. When you first buy a new car, it’s shiny and new, and everything works perfectly and performs at its maximum efficiency (or at least that’s the idea).
But a new car requires regular maintenance to keep it in tip-top shape. Tires wear out. You need to change the engine oil (in a gas powered car). You need to change the transmission fluid, the spark plugs, and a whole lot of other things that require replacement over time.
Neglect replacing these things over time and you’re going to end up with a useless hunk of metal and rubber that will no longer run, let alone take you anyplace.
The same goes for software. Software doesn’t have any physical components, but that doesn’t mean it doesn’t require constant maintenance.
No software application is perfect. There will always be design flaws and bugs just from the simple fact that software is created by us imperfect humans. Software is simply a manifestation of our human goals and desires, and our inherent flaws as people will always show up in one form or another in our software. Period.
The business requirements for a software application may change over time, simply due to the fact that companies evolve and shift priorities over the course of its history. Software doesn’t magically correct itself to adapt to the changing needs of a business.
And finally, the entire technical stack which your software is a part of, eventually ages. In the early age of computers, big mainframe computers were king. Many businesses like financial institutions, government, and military agencies often used high-level programming languages like COBOL, to power their businesses.
And to this day, many banks and other organizations continue to use COBOL and the mainframe systems running COBOL programs.
But the world continues to move on. Those old systems continue to run, but the original designers and programmers who built those original systems, are either retired or long since working in other occupations.
Where are you going to find any new generation of software developers who are willing to learn those old systems?
Most software developers, including myself, are interested in learning new technical stacks and languages. One, because we are naturally attracted to shiny new technology. But more importantly, in order to keep marketable in the job market, we have to continually invest and train ourselves in new technology.
My current employer is actually facing this exact dilemma right now. For 25+ years, their core technical stack has remained the same. And the people who knew those original systems and how they were constructed are no longer with the company, either through voluntary retirement, or forced company layoffs.
But that core technical stack is still there. And if nothing is done to replace their aging technical stack, they will eventually run into the unfortunate situation where there will be nobody left who will know those original systems.
Technical debt naturally creates aging systems that become very difficult to maintain and keep up and running.
It also makes it difficult for an enterprise software developer to figure out how to build new applications and systems on top of those old aging systems, because the knowledge base for those old systems is rapidly dwindling down to nothing.
The other major difficulty behind enterprise development is more a human problem. It’s something I like to refer to as the “silo effect”.
If we go back to the example of a company that makes and sells farming equipment for revenue, you can think of the sales and marketing department as a silo. The order fulfillment/manufacturing arm of the company is yet another silo. The shipping department is another silo.
They’re all concentrating on their own specific business needs. Someone who works in the sales department really doesn’t concern themselves with the actual manufacturing and shipping phases of their product … the only thing they care about is trying to generate as many sales as they can.
Similarly, the manufacturing wing of the company could care less about HOW a new sales order gets generated. They only are concerned with the process of manufacturing of the product. Similarly, they don’t concern themselves with the shipping of their product. That’s the shipping department’s responsibility.
And what inevitably happens is each of these separate silos create software and systems that only concern themselves with their specific business needs.
For example, the sales order department is only interested in using software and systems that revolve around the process of generating and maintaining new sales orders.
The manufacturing department is only concerned with software and systems that help them keep track of physical inventory. And likewise, the shipping department is only concerned with software that keeps track of shipping orders back to the original customer.
Oftentimes, many of these systems are built independently of each other, without any regard for communicating with each other.
This is ultimately where the challenge of enterprise development comes into play.
If you’re an enterprise software developer or architect, your job is to create a software and hardware ecosystem which allows every arm of the company to smoothly work together and create a seamless sales, supply chain, and shipping system.
But if none of these silos were originally designed around the goal of interoperating with other silos, you end up with a giant mess of redundant systems, software and duplicated code.
I’m dealing with this very challenge right now in one of my current projects. As I’m analyzing the business requirements of my project, I’m discovering tons of redundant business processes and duplicated software systems that are all “reinventing the wheel”.
None of the systems can easily communicate with each other, if at all.
It’s going to be a bear of project, without a doubt.
But it’s also going to be challenging in a fun way, trying to figure out how to get all these disparate systems to work better with each other and eliminate as much clutter and redundancy as possible.
If you’re looking for job security in information technology, then you’ll be wise to consider getting into the world of enterprise development.
I’m not sure what other kind of task can be more challenging.
Herding cats, maybe?
