Experts’ View on Enterprise Software Development

Posted by Paul Anderson

Experts’ View on Enterprise Software Development

Old techniques to build enterprise software applications no longer hold value. Organizations need to follow contemporary practices for successful Enterprise Software Development.

A group of experts (Richard Soley, Calvin Nieh and Larry Freeman) proficient in cloud computing and information security cites a resourceful insight on this topic. Taking excerpts from their latest report (The Modern Take on Enterprise Software) – here’s a snippet on Enterprise Software Development best practices:

Today, it’s all about agile processes which have radically changed how organizations approach enterprises software development.Unlike the old way of building elaborate models and dictating technology choices – there’s an emphasis upon a strong collaboration between the development team and the end users.

Paraphrasing the comments of Richard Soley –

In today’s nimble and fast-paced development environment, Enterprise Software Development teams working in a collaborative and lightweight manner have a higher ratio of success. In such an approach, the enterprise architects are not producing a lot of documents or models because detailed artifacts tend to be ignored by the end users.Rather they are collaborating with the companies to comprehend the enterprise architectural vision and accordingly proceeding to build it out.

So you can say there’s a direct correlation of success for software development teams working in a collaborative, lightweight manner.In contrast software application developers that are still working in the traditional models have a much higher failure rate.

Calvin Nieh managing consultant at IBM states –

“majority of developers who resort to traditional Enterprise Software Development techniques fail in developing the right enterprise architecture because of lack of teamwork. With zero collaboration between the development teams and the end users, software developers work in watertight compartments for months. All they come out with are complex models that eventually no one understands and uses.”

Larry Freeman seconds this thought, claiming Teamwork as one of the Basic Fundamentals of Enterprise Software Development.

Paraphrasing his words – The key best practice for both the developers and the company is to make sure that everybody in all of the departments — understand the principles behind the software development.Once the end users see the value in incorporating the enterprise software application, they easily buy into it. In other words, the hassle of less user-adoption gets completely removed.

In addition to easy user adoption, making the developers work closely with the end users also facilitate in the incorporation of new architectural principles. For instance, when the end users are directly involved in the development process, they provide technical consultation, design and review capabilities, on time whenever required. Consequently, it’s relatively easier for the developers to accomplish what the end users are trying to achieve through the Enterprise Software Applications.


Having said all the above-mentioned pointers, what’s important to understand is that it’s not simply enough to implement the changes from the development side. To really go for agile Enterprise Software Development, organizations too need to make certain improvisations in placing their requirements. In parallel, they need to empower the development teams to flag up when a few aspects within the enterprise software application isn’t compliant with the present architectural principles.

Experts suggest – dedicating time on studying and analyzing enterprise architectural requirements. During that process, the non-functional requirements are removed. Similarly, technical spikes that may require more time (due to introduction of a new technology or data migration, etc) are identified and accommodated accordingly.

Overall, this procedure works well because it gives a strong focus on understanding enterprise software functional and non-functional requirements — and these are the things that often go overlooked many times.