5 Critical Lessons from Developing My First Enterprise Application

I started working for a solar company in college while finishing up my Master’s degree at Brigham Young University. I began doing sales for them initially just to put me through college, but then I transitioned to their corporate team when I eventually became they’re VP of Technology.

I worked for them part-time (“ish”) while I was in school and started on full time after graduating. I was in charge of all their IT Operations and software development. We had 2 main teams in our department, one handled our software integrations to manage our sales flow process and then other handled development of internal applications.

I was able to lead out my first enterprise web application development project with a team of 5 while I was still in college, which was a firehose of experience. I worked directly with the executive suite to roll out this application.

We were able to build a web-based sales portal for the company’s sales reps so that they could track their sales metrics as well as run competitions with each other to compete and win company prizes.

I learned a lot of lessons along the way. I failed a lot and learned a lot as well. Here are the top 5 lessons I learned so that you can learn from my mistakes.

1. Data Matters

Understanding your the state of your data REALLY matters when beginning the process of building an enterprise application. When your main stakeholder has a need that you can solve, it’s important to break down the data you have available to you to ensure the end goal is even possible.

Ask yourself questions such as…

• How much data to we have to deal with?
  • thousands vs millions of records?
  • 20+ tables?
  • 400+ fields?
• How disorganized is our data?
  • How many duplicate records?
  • How many duplicate fields?
  • How many fields without data are there?
• Where is your data located?
  • Various databases?
  • On a SaaS platform?
  • Google Drive?
  • Snowflake?
• How hard is it to pull your data into one place?
  • How often does data need to be synced?
  • How many sources of data are there?

These sorts of questions allow you to get a better understand of the state of your data you are working with and the amount of work it will take to consolidate your data for your application.

If building an application were a giant, Death Start Lego set, this step would be just separating out all the pieces from each bag so you get a view of what you are looking to build.

From here, we must understand the end goal of your stakeholder and how your data will get you there. It’s important to recognize the data we have readily available to support getting to the end goal, as well as any data we are missing.

Separate your data out into “must haves”, “probably should have”, and “nice to have” data. If you have any missing “must have” data, then it’s important to communicate that to your stakeholder, because it’s a serious roadblock.

Note: Just like you don’t know if you are missing any pieces when you start your lego set, sometimes you don’t know you have missing data until you start building. It’s important to keep this in mind to recognize project changes when new information comes to light.

Make sure you can map out and connect how your current data gets you to the end goal the stakeholder wants. If you can’t find that connection yet, then you shouldn’t start the project.

Also, don’t overcomplicate it. I’m a big fan of Occom’s Razor…

"With all things being equal, the simplest explanation tends to be the right one."

So find the simplest solutions to solve your stakeholders problem. Don’t over-engineer it.

2. Don’t Spend too Much Time on Diagrams

Building out some architecture diagrams is important, but you must understand who they are for. Architecture diagrams are purely meant to help the team understand the application’s state and be aligned on what they are building.

And this might come as a surprise to some people, but your stakeholders, especially if they’re high-level, could CARE LESS about diagrams. That’s like saying you care more about the Lego instructions more than the actually finished Lego set.

Focus on building out a solid Domain-Class Diagram and perhaps a couple sequence diagrams depending on how complicated your app is. But then quickly move on to start building.

Your diagrams are going to change as the project progresses so make sure to update them and don’t get caught up in making it perfect initially because it won’t be.

Your first class diagram is a rough draft, the final draft is the app. Remember… the end goal is an app that solves a business case… not a class diagram.

3. Be Willing to Throw Out Project Plans

This is where the Lego analogy breaks down a bit, since everything is consistent with building a Lego set. Unfortunately, developing enterprise applications is not like this.

Outlined project plans are great until they aren’t. Most of the time while developing an enterprise application, new information comes to light that you did not know when you outlined the project initially.

It is essential that you pivot your project plan to adjust to new information once it arises.

The great creator of the SCRUM project management framework, Jeff Sutherland, once said…

"Embrace the unknown! That’s where learning lies. If you’re too afraid to learn, you will never get any better. This is key to being successful at Scrum: embrace change."

Make sure you embrace changes when they arise in your project so you can pivot and be successful. Remember… the end goal is an app that solves a business case… not a project plan.

4. Manage Expectations with Stakeholders

This is kinda a, “Yeah, no duhh” lesson but it’s way easier said than done. I would argue that this is the hardest lesson for people to learn coming from a technical background.

Learning how to deal and manage people might be the hardest part of developing an enterprise application. The important piece is to BE TRANSPARENT.

Sometimes people are afraid of letting their stakeholder down if the project is not on schedule or over-budget. Well, do you know what’s worse than bad news about a project? Bad news that’s delivered too late! Because you weren’t willing to have tough conversations.

Having tough conversations is a part of the job and are NECESSARY to have a good relationship with your stakeholders. So get used to having tough conversations.

I’ve worked with many executive-level stakeholders. And most of them are very understanding when there is a curve-ball in a project and plans change. This is something they deal with on a daily basis so they are used to it.

Most of them are understanding if projects change, but they are NOT understanding if you tell them information when it’s too late. If plans change, tell them IMMEDIATELY.

Also, don’t just come to them with a problem. Approach them explaining the issue and your solution so you come off as competent and “in-charge”. If they sense any weakness, they will doubt your ability to follow-through. You know what you are doing… so act like it.

5. Quantify Your Output

It’s really hard to say you did a good job if there’s no way to measure it. Make sure there is a way to quantify your impact to your stakeholder so they can see the tangible results of your app in their business.

I failed to do this for my sales portal app I built for the solar company. I built a really cool app that the stakeholders liked, but I did not measure how it improved sales efficiency of sales reps.

Understanding the objective measurement that ties to the stakeholder’s end goal is vital to show you impact on the business. So at the end of the day, you can show off your “Death Star level” results!

Overall, developing enterprise applications is really really hard. You have to think ahead, stay on your toes, and be very diligent about managing expectations with stakeholders.

Be patient with yourself and learn from your mistakes. It’s a long, never-ending journey of learning but it becomes very rewarding to see and understand your value.