Hi there!

These days it’s quite common for big enterprises whose core business isn’t IT to outsource their work to third-party providers. Here lies their main mistake - misunderstanding of competencies that are “outsourceable”. The enterprise’s managers frequently forget that any modern business is an IT business. Consequently, you have to keep core IT competencies on the company side. Otherwise, the huge dependency on a third-party provider will be created.

I’ve seen and heard many stories on how a project has failed due to lack of vision, lack of competencies, lack of resources, etc (I’m pretty sure you have your own story of a project failure, I’ll be happy to hear it). Consequently, I truly believe that there are four areas where you must have a core competency in your company to deliver a successful IT product: user research, API contracts, solution architecture, and data modelling. I truly believe that certain areas of IT such as coding, high fidelity mockups, quality assurance, project management have been heavily commoditized. Thus, it will be possible for you to find a reasonable replacement for a particular function. On the other hand, if you have no clear vision of your product architecture or you can’t answer who your users are, your project is doomed.

Let me deep dive into each area and explain my thoughts.

User research

It’s difficult to overestimate user research. You have to know who is going to use your product. Can you define personas and user journeys? Can you link your deliverables to user needs? If you answer “no” to any of the above questions then you have to revise your product development model.

If you don’t understand who will be your final user, why are you building the project in the first place? You have to spend some time with your management team to identify the correct personas, user stories, benefit hypotheses, etc. Once you gather the required information, you have the fundamentals to start working on a project.

API contracts

The second important area is API contracts. Firstly, what is an API? To put it simply, it’s a way computer programs interact with each other. I believe that the majority of readers are IT-savvy people, so I won’t spend time explaining what API is, but if you are keen to see a very clear explanation here is a splendid video that explains this concept extremely well.

What types of APIs are usually available in the information systems? In a nutshell, there are two types of APIs: internal and external (or public). Which one is the most important? A lot of people would say that the external APIs are the most important, and to an extent they’ll be right about this. On the other side, I would argue that a clear definition of internal APIs is critical. Let’s talk about each type of API separately.

The public API is the front door to your application. Your public API defines how the final user interacts with your application. If you won’t think your API through and don’t provide good documentation, your client’s user experience will suffer. And if the client suffers, your business will suffer too.

The private API is important as it defines a level of coupling in your system. If you have a high coupling in the system, one mistake can cause a snow crash effect. Your IT system will fall like a set of dominos. In addition, the poorly defined private API directly affects developer’s productivity.

Architecture

The next crucially important thing is your solution architecture. What do I mean by solution architecture? It’s everything you need to create your application: information architecture, infrastructure architecture, application architecture etc. In short, the solution architecture is a map of your application development. How detailed should it be? Should it describe each and every path or high level details? These are questions for you to answer.

Is it possible to successfully run a project without a well-defined architect? Obviously, yes. But is it possible to sustain a project’s expansion and development over time without architecture? I doubt it.

Data Modelling

The title of a famous book by Niklaus Wirth, who is one of computer science pioneers, is “Algorithm + Data structure = Program”. The data model, which is a modern “data structure”, is almost half of your information system. It’s impossible to underestimate the importance of the data model in an early stage of the software development, when you “just need to store it somewhere”. But at a certain point of time you might have a lot of “data model intensive” requests related to audit, compliance, complex reporting, etc. Does your data model support it by design? If the answer is “no” you should be prepared for a complex, error-prone, and costly refactoring. Thus, I always think it’s a good idea to spend time during your planning phases to accurately design your data model to avoid potential issues in the future.

The above four items don’t form an exhaustive list, but I would argue if you are building a relatively complex application, you will not want to let go of control of the above areas.

Do you think differently? Please, feel free to comment or drop me a message, I’m always happy to have a nice conversation!

Stay tuned!