There Are Many Impactful Subtleties CIOs and Other Ranking Corporate Officers Should Be Aware of When Looking to Develop Enterprise Software for Their Companies


It may be no ground-breaking news, but roughly half of enterprise-grade software development projects turn belly up the first time around. They either have to be rescued by their owners to survive (certainly, by throwing tons of good money after bad) or are just abandoned to their fate.

Numerous headlines having been made and whopping losses (some have reached hundreds of millions of dollars) incurred by iconic market players in a bunch of industries, we seem to be no closer to a solution than we were, say, 10 years ago. Why?

In our view, there are just too many devils in the details on different levels (both technical and management ones) even quite experienced enterprise software providers are not yet aware of. Many of the things that seem like no big deal, but are, potentially, able to derail a project have to be learned empirically, as they aren't mentioned as part of any formalized domain-specific knowledge.

To complicate matters even further, a lot of the time these hazards have to be dealt with collectively by many different project stakeholders, including those, who represent the client.

Among other things, we’ll share with you in this article several such empirical insights of the great many we’ve picked up while building enterprise-grade software. If your company is looking to have an enterprise application developed for it, these tips may help you keep better tabs on your software development contractor (that, as time has shown, may, or may not be aware of them).

Big-Time IT SOLUTIONS to BIG-League ENTERPRISE CHALLENGES

Development-Related Tips

  1. First and foremost, most enterprise software development projects are, usually, wide-ranging development efforts. They involve a number of experts, each of whom has their own coding habits and their own idea about the way code should look like. After a while, these, often conflicting, views and habits result in a coding mess that becomes difficult (if not completely impossible) to manage or straighten out, while also preventing newcomers to the project from getting a handle on the project specifics within a reasonable space of time.

    Development Guidelines

    Because of this, one should never embark on an enterprise software development project without introducing a set of detailed and well-thought-out Development Guidelines. These guidelines must stipulate rules that will allow one to ensure uniformity of all the input, provided by the different project contributors. Notably, the above rules must detail the requirements for the code to be written (the use of blanks, tabs, case styles, naming conventions, etc.). Make sure that all those, involved with the project, are well-aware of, and strictly follow your Development Guidelines.

  2. Similar to Point 1, quite often, the several development teams, implementing an enterprise software development project, have varying ideas about what can be considered as “done” or a fully and duly completed assignment. This entails frequent misunderstandings, longer turnaround times, and, sometimes, even, attempts at blame shifting.

    That is why, prior to kicking off any enterprise software development effort, one should compose, discuss in sufficient depth with all the development teams, and formally introduce a set of “considered as done” criteria to be universally upheld by all of the above teams. For example, such criteria can include:

    • Coded

    • Compliant with the project-related guidelines.

    • Meets the project-specific acceptance criteria.

    • Committed to a Team branch.

    • Compilable

    • Duly documented

    • Unit Test coverage is no less than 80%.

  3. It is simply imprudent to start an enterprise software development project without defining the areas of responsibility and making corresponding personnel appointments.

    With Agile enterprise software projects, a good rapport between the different development teams is central to a project’s success. This is best achieved with the help of written working agreements between these teams, adopted project-wide.

    For instance, such a written working agreement can include the following clauses:

    • Code is to be written solely in accordance with the project-specific development guidelines.

    • For Sprint-related work, Team branches are to be used.

    • Only those features, that are in compliance with the adopted “considered as done” definition are to be committed to the common development branch.

    • Nothing can be committed to a red build (or a build that has failed testing and, thus, is not compilable for some reason).

    • No code that has not undergone a code review can be committed.

    • The Product Owner is to be constantly available to answer questions by the team members.

    • Nobody can ever late for a meeting.

    • Nobody can come to a meeting unprepared.

    The whole thing must be supported/promoted by the PM.

  4. It is imperative that all project tasks are track-recorded regardless of their size. Failing this, you may wind up with a massive amount of poorly manageable code, dealing with which will be irksome and extremely time-consuming. Your developers will have to turn themselves into full-time investigators every time they come across an obscure spot in the code. Again, this spells a real pandemonium for those, joining the project at a later stage.

    From our experience, you can enhance the readability and ease of use of your code base immensely by integrating Git and Jira and using the integration for source control purposes. It will become possible to immediately view history for any of the code changes (in plain talk, when and why a change was made, who made it, and what exactly was done). In any event, it is an absolute must that one follow the Agile paradigm: "Plan what you do, and do what you plan."

Project Management-Related Tips

  1. Try to determine if there is a need for Stakeholder Management being part of your Project Management process. Once unidentified at the beginning and overlooked later, this need becomes an insidious scourge that can, in due time, affect a project negatively on a much larger scale than a mere technical issue.

    So, just in short, what is Stakeholder Management, and why is it of so much importance?

    Stakeholder Management is the process of identifying pockets of resistance, formed by those of an organization's employees, whose interests are opposed to the project-empowered change.

    Few executives want to believe there can be some undercurrents in their companies that are at variance with whatever is said at high-ranking meetings and festive corporate parties. Alas, this happens all the time. Most frequently, this happens when the changes that are likely to affect the interests of a specific group of employees (or, even, those of individual employees) begin to loom large and send jitters across the organization. In this case, some of those concerned fail to see any upsides the forthcoming innovations can create for them personally, while setting too great a store upon the possible disadvantages and risks they may be exposed to.

    You, simply, cannot afford not to identify such employee groups or employees, and alleviate or dispel their fears by explaining to them how your project will benefit them. In the absence of this, the fallout can include a severe lack of cooperation, deliberate protraction and missed deadlines, and, eventually, a stalemated project it will cost you a mint to bring back on track.

    Your options here can range from corporate perks and the opportunity for such employees to acquire some new, valuable professional skills, to giving these guys a chance to start performing less chore-like and more interesting tasks.

    Stakeholder Management

  2. With Agile-driven enterprise software development projects, Product Owners tend to be regarded as a kind of semi-deities, who cannot, even, always be available for a conversation. This approach is totally wrong.

    New requirements come into being continually and things get modified on the fly all the time. That is why, the Product Owner must be an integral part of the team (both constantly within reach and actively involved in the team effort) for those changes to be handled properly. Moreover, they must share full responsibility for the team’s work results and take active part in the performance of solution reviews, conducted at reasonable intervals together with the other team members.

Testing Automation-Related Tips

In enterprise software development, Testing Automation tends to be thought of as a kind of a silver bullet. It is widely held that once you have a certain number of automatic tests in place, everything is well-taken care of QA-wise. This is a very troublesome fallacy.

In actuality, Testing Automation pans out only when handled properly.

These are the more meaningful tips we could offer testing-wise for “mess avoidance” purposes:

If you already have some lengthy and complicated tests being used or in the works, have those split into smaller-sized ones: even if everything’s Ok so far, the likelihood of future problems arising is quite high.

Incidentally, overcomplicated and overextended tests can significantly hamper, or, come to that, even, ruin altogether your Continuous Integration process, if, of course, it is the approach you use.

  1. Keep all your tests small. Your tests must pinpoint a specific problem and focus on a specific task. One should try to minimize the number of wider-ranging tests. Preferably, the latter should only include a small quantity of integration tests that aim to ensure that the different system modules interact seamlessly. Otherwise, if one of your tests flunks at a future date, it will become immensely time-consuming and labor-intensive to figure out what the problem is: one will have to unravel a long and convoluted testing history to get a fix on it.

  2. All the tests must be unrelated to one another. If this is not stipulated from the outset, you may well encounter a couple of really nasty scenarios.

    For example, if your tests are linked in one way or one another, one single test failing may cause several hundred other ones to go haywire, without giving you any clue whatsoever as to which of them is at fault for the mess.

    Similarly, any change made to one of your tests will, inevitably, entail making changes to the rest of your tests. In addition to the whole lot of trouble both the scenarios can create, they will also be sure to set your testing costs soaring.

  3. Stick to Martin Fowler’s test pyramid. The vast majority of your tests must be Unit ones. Only a very minor part of your tests can be Integrated and UI tests.

  4. Software developers, no matter how skilled and good at programming, tend to be lousy indeed at writing test cases. We’ve seen plenty of this stuff and there are either lots of cumbersome overlaps or something that really needs to be tested just gets left out.

    Conclusion: all test cases must either be written by a well-qualified QA engineer (this should, preferably, be a separate project role), or, at least, reviewed and approved by a well-qualified QA engineer. Thus, Quality Assurance must become an integral part of your development process.

  5. To ensure smooth and uninterrupted Continuous Integration, one should make sure his builds don’t take too long to be executed, and the build results are analyzed reasonably quickly.

Related Articles

System Integration: How to Achieve Better Results with Integration Use-Cases
Application Integration , Business analysis

System Integration: How to Achieve Better Results with Integration Use-Cases

System Integration is an extremely complicated and effort-intensive process, especially, if more than two enterprise-grade systems are integrated. The conventional Business Analysis means, often, fall short in the latter case, and the need to capture the multiple complex system integration processes turns into a real challenge.

Being a team that has been engaged in the provision of Telecom system integration services for a very long time, we’ve devised a proprietary BA tool that has helped us optimize the system integration process very significantly.

Read More
Business Analysts: Who Do You Really Need to Help You Automate Your Business?
Business analysis

Business Analysts: Who Do You Really Need to Help You Automate Your Business?

Business analysis services seem to be in lesser demand than most other IT-related services. Being, frequently, underestimated, Business Analysis expertise is, in many instances, essential for the development of complex enterprise software.

There are different types of Business Analysts. While implementing a complex IT project, it is important to know what exact kinds of Business Analysis expertise and Business Analysts you need.

How to determine this?

Read More
5 Ways to Drive One’s Agile Enterprise Software Project into Ground,  and How to Prevent This Happening
Enterprise Software Development

5 Ways to Drive One’s Agile Enterprise Software Project into Ground, and How to Prevent This Happening

The Agile methodologies are often used to implement enterprise software development projects. However, the normally large scale of these projects creates the need to mitigate the Agile-related risks even more thoroughly.

While a lot has been said about the Project Management practices that help reduce Agile-related risks, some of the potential problem areas are seldom, if ever, spoken about.

Read More