This blog is all about enterprise software development. So, why not make the first post about what enterprise software actually is? Brilliant, right?

Enterprise Software isn’t a standardized term. It depends on your point of view. Enterprise Software means something different to a CEO or CFO than it means to a developer.

If you want to come up with a definition that everybody can agree on, you can’t go into too much detail. The best I can think of is Enterprise Software cares about the company’s business. That’s what separates enterprise software from other software you find within a company. A word processor, for example, doesn’t care about the company’s business. It simply doesn’t know anything about it. That’s why I don’t consider a word processor as being enterprise software, even if it’s used for some business tasks.

Enterprise software, on the other hand, knows a lot about the company’s business. It’s designed for a specific domain and can’t be meaningfully used in other areas.

Characteristics of Enterprise Software

As a developer, I like how Martin Fowler defines Enterprise Software in his book Patterns of Enterprise Application Architecture. He doesn’t try to reduce it to one sentence or paragraph but defines it by some characteristics that are common to most enterprise software projects. (There’s also an updated blog post.)

Data

There’s a lot of data. Seriously. And it’s not just a lot, it’s also many kinds of data. All that data needs to be persisted - potentially for as long as the company is operational. But that doesn’t stop the application from changing. So, the data has to keep up. Data transformation and adoption is a constant challenge.

Data integrity is another major aspect. There’s not just one user accessing and manipulating data. There are many users - sometimes working with the same pieces of data at the same time. It’s the job of the enterprise application to make sure that the data is always persisted in a valid state, nevertheless.

User Interface

Where’s a lot of data there’s also a lot of different views to present all that data. It’s not unusual that one piece of data is presented in many ways depending on the business context it’s used in.

The users aren’t experts in software development but in their field of business. Therefore, technical details should be hidden from the users wherever possible. A good user interface guides the user through the business task and makes work easier, faster and maybe even more fun :-)

Business Logic

Then there’s what’s called business logic. But don’t be fooled by its name. It’s not always logical - at least not to us developers. The business logic is the core of the application. It’s the implementation of the business rules and know-how. It’s what the company does, expressed in code.

The business logic can get quite complex. The single steps of a business rule are usually simple. It’s the many special cases and dependencies that make it hard for us to implement, test and maintain the code.

What Does That All Mean for Us Developers?

Let’s get to the important question. What does it mean to be an enterprise software developer? How is it different from developing other types of software? The following points only scratch the surface. But their implications are ultimately what this blog will be about in the posts to come.

You Are Not on Your Own

Enterprise software development is a team sport. You can’t do it on your own. Even if there is some niche in the code base where you work in exclusively, eventually your code will have to be integrated with the rest of the system and you will have to work together with other people. But it’s not only that you have to, you should actually be looking forward to it! Collaboration done right is extremely beneficial to the team, to the quality and success of the project and also to yourself. If you want to become a great enterprise software developer, you have to become a great communicator. Soft skills are important - don’t neglect them.

Embrace the Domain

Talking about soft skills … As an enterprise software developer, you have to work together with domain experts. They are the ones who know what to implement, but they have no idea about how to implement it. That’s alright. It’s our job to translate the domain requirements into software. That’s not an easy job. To be effective and to minimize translation errors, you have to become adept in the domain to.

You Don’t Own Code

It doesn’t matter who writes a piece of code, it’s always owned by the team. That means, other developers must be able to read, understand and change the code you wrote. Writing code that works isn’t enough - code has to be maintainable.

Long-Lived

Successful enterprise applications have a long lifetime. Something like 10 to 30 years is a realistic time range. But it can be even longer. However, enterprise applications are never finished. Change is a constant companion. As a result, the code base and the amount of persisted data is going to be huge. A smart organization of your code and data is vital.

In such a long-lived application you will inevitable have to deal with legacy code. Even if the developer who initially wrote the code is still working at the company, chances are high he or she can’t remember much about it. Hopefully, the author did put some extra effort into writing maintainable code, if not you have to deal with it anyway.

Bugs

No user likes bugs. But bugs in enterprise software can be really costly. It depends on the business you are working in but, honestly, there’s no upper limit in monetary damage a bug can cause.

There’s one bitter truth we enterprise software developers have to accept: no one is using our software for fun. It’s always about some business task that needs to be done. To users, an enterprise application is a mere tool. Unfortunately, there’s not much bug tolerance when it comes to tools.

Technical Change

Technical change tends to be slow in enterprise software environments. You have to be cautious about new technologies. Is it just another short-lived trend, or is it something you can build on for the next years (or decades) to come? On the other hand, sticking with an outdated technology for too long can become a serious competitive disadvantage. At the end, it’s the responsibility of us developers to decide which tools and technologies we want to use. We can’t offload the decision onto management. It’s a technical decision - we are in charge.

What do you think does it mean to be an enterprise software developer? Is there something important I’ve missed? Did I get something wrong? I’d love to hear from you in the comments.