Seven Practices For A Highly Effective Architecture



Software systems are getting ever bigger and complicated while their Time to Market (TTM) is shrinking ever shorter. At the same time the cost of failure for the software implementations is getting higher. From the technology standpoint architecture is the blueprint for the system. Criticality of the architecture piece in the success of any IT system necessitates taking all the precautions getting it done right the first time. IT has established itself as a business enabler and serves as one of the prime drivers for the business growth. This changed business landscape, with its high dependency on IT, demands looking at the architecture development process from a fresh perspective. In this article we will discuss seven of the crucial practices that are important for developing architectures that survive and succeed.


Independent research groups have identified lack of proper communication between the various stakeholders as one of the biggest failure factors for an IT project. The data shows that more than 50% of the projects that failed could have been saved if the folks in the team had taken keen interest in understanding each other. Why there is a lack of effective communication across the team, even when there is a lot of communication going on?

Communication is a vehicle to transfer our thinking among ourselves. We package our thoughts in the vocabulary and language we understand, often ignoring the fact that the receiver might be having her own set of vocabulary and language. The meaning of what has been communicated could change drastically after the receiver converts and translates it into her own terms. IT projects are team driven and creating a common vocabulary could be a daunting task. Given the heterogeneous nature of the IT teams, it is no wonder that the effective communication is a challenge.

At a high level any IT project will involve people from the following groups:

  • Business Managers: They have the vision of the future. They may have directional idea of what has to done but may not be exact about how IT can be an enabler for realizing that vision.
  • Business Users: They know how the business operates and it intricacies, challenges, opportunities, existing environment etc. They will understand the management’s vision in business terms but not the technology that could make it happen.
  • Project Managers: People who will be executing the project once approved and are more concerned about the resources, efforts and timelines. They could have idea of the vision of the Business Managers, but not much knowledge about the functional and technical aspects of the project.
  • Technology People: People who understand the technology and the implementation. They will not have detailed knowledge of the business functions though.

The above descriptions have been framed to make the groups exclusive to highlight the challenges. In actual the team structures and the expertise of the members will vary case to case and may not be this exclusive. As we can observe, each of the groups hold knowledge of one of the critical pieces and lacks knowledge of the other important piece. All the groups must have a common understanding for a project to succeed and to have that they must speak a common language. This poses a big challenge as team members do have different backgrounds, they see the things differently and talk about them differently and have different focus areas. There are natural hurdles for them while communicating with each other. So it will need conscious effort on the parts of the business people to make the technology people understood what they do mean. This can happen only if the business is the language spoken and entire team understands it.

There is another very important aspect to it. Experts who are watching the trends and the tech gurus are settling their minds with the fact that the line between the business and IT is disappearing fast. IT is getting into the DNA of the business rather working in a silo. Business and IT are proliferating into each other’s domains so fast that in near future there will be no space that could be said exclusive to either of them. So that too will necessitate the team to think in the terms of the business.

Last but the most important point is that in the changing business models, IT Service providers are seen as business partners and not just vendors who provide services. Service providers do have stakes in the success or failures of a project beyond the project implementations. Technology solution providers will need to go beyond solving a business problem and actually see the opportunities of improvements proactively. This can happen only if they have a fair understanding of the business and they speak in the language that business people understand.

Here are some practical tips:

  • Give the business user and domain folks all the available time affordable to speak out themselves to the rest of the team
  • Put efforts and have patience until there is a consensus over the understanding
  • Avoid the technology discussions until technology people have some comfort with the business domain
  • Once the technology blue print is available give a walkthrough of the same to the business people, and pay attention to what they have to say, even if it seems not so important
  • Set the agenda for the discussions prior to the meeting – business focus or technology focus, don’t allow the discussion to be hijacked from its agenda
  • It is good to have a few team members who understand both the technology and the business and keep them as a coordinator for the discussions
  • Let technology folks present their understanding back to the business folks and get their understanding verified


Managing the complexity of the IT systems has been one of the prime concerns for the architecture discipline since its inception. The acid test for any futuristic architecture would be its simplicity in solving the complexities. If the architecture doesn’t have that beauty, it will become an added complexity to the already complex business. The architectural best practices in themselves are not the magic wand ensuring the project success. They are just the tools and need to be implemented correctly. If the process has been started right and all the groups are talking in the business language, following would help in formulating an architecture that is not overly complex.

  • Think the architecture component and flows in the terms of business functions and workflows
  • Consider using a product over the custom built tool if possible
  • Think though the integration across the enterprise and beyond to see if it demands an enterprise level service bus
  • Consider asynchronous and batch processes over the real-time processing, if real-time response is not required, asynchronous processes can simulate near real-time results if designed well
  • Use the industry standards for building pieces like security, communication, integration etc. so that they are future ready and flexible
  • Create the high level Reference Architecture blue print and Architecture Guidelines for the enterprise and set the focus for the further evolution of the same


Non Functional Requirements (NFRs) are something that we often tend to ignore in the early stages only to regret later. A project must define its basic non functional features as early as possible and definitely well before any concrete architecture level decisions are made. Considering the non functional aspects of the requirements as an afterthought is always very expensive and many a times even impossible task, as far as the implementing architecture level changes is concerned. Advent of internet, mobile computing and cloud based programming has increased the criticality of NFRs by many folds and had an impact not only over the way the applications are designed and developed but also the way they are tested, deployed, maintained, billed and finally retired. Not giving them the attention they deserve could be potentially disastrous. Identify the non functional requirements for the application from the following areas and consider the results as a vital input to the architecture decision making:

  • Functionality
  • Usability
  • Reliability
  • Performance
  • Security
  • Supportability
  • Interfaces
  • Deployment


At a very high level there are two drivers behind the changes- survival in the highly competitive market and growth. First, the ever changing market demands driving the businesses to accommodate themselves to the market changes quickly. The faster they can do the adjustments, higher the chances of their survival. Second, studies show that businesses need to keep on reinventing themselves in order to grow. Even the technology changes are driven by these two factors. As it is very clear technology in itself can’t make the business survive and grow. It serves as an enabler tool if implemented and leveraged correctly. Sadly it can be a disabler as well.

An ability to absorb changes (be it in the functionality, environment or in an interfacing application) contributes a lot to the success of a software implementation, although there are multiple other factors as well. It is important to note that the flexibility to accommodate to the changes will be getting more and more important and become the prime success factor as the time passes on.

The whole paradigm of architecture discipline has been in a way guided by providing the implementations to be flexible. From the concept of functions, to libraries and multi tier models to SOA, all has evolved to make the various small components work together to make a larger system and increase the life span of the implemented software.

Building for change not only includes the changes in application functionalities rather also a change in the environment, usages patterns, connecting applications and deployment models. Building for change means developing an application as a piece, that can work well together with the others pieces, when all the pieces and the associated environments are changing themselves.

If the NFRs have been analyzed properly they can serve as vital inputs here. Apart from that some pointed “What If” questions should be asked unearthing the hidden change related requirements.

  • What if a major business function needs to be changed?
  • What if a new business function needs to be added?
  • What if the application needs to connect to another application?
  • What if the application needs to be hosted on a different platform?
  • What if the application needs to be exposed to internet or hosted over the cloud?
  • What if the application usages increase by many folds?
  • What if a merger and acquisition necessitates co-existence with a similar application?


More people in the U.S. will access the Internet via mobile devices than through desktop computers or other wired devices by 2015.The researcher predicts sales of all wireless device sales in the U.S. will see an annual growth rate of 16.6% between 2010 and 2015. – IDC Prediction

India’s Internet users will increase fivefold by 2015, and more than three-quarters of them will choose mobile access. – Gartner Report.

The fact of the day is that predictions and survey results like this do not surprise us anymore. Internet has shaped the way businesses are done today. But in the coming future it will shape the way humans live their daily lives. One corollary to these facts is that there will be hardly any significant difference in the business and daily lives as far as their technology underpinning is concerned. It means:

  • People will use multiple devices for achieving the same task
  • Task initiated from one device might get completed from another device
  • Task might continue when user is not online
  • There might be a team behind the task spread globally using not only different devices and service providers but also different languages, cultural preferences etc.
  • People will continue working even when they are not in the office environments
  • Work and social interaction (primarily done through mobile devices) will get integrated together

The architects for the application must ask the questions how much mobility support the application will need. If there are no such requirements for now, is there a possibility that such requirements will emerge in foreseeable future. It is highly likely that if a solution has a future, it has to support mobile devices in one or the other way.

Leave a Reply

Your email address will not be published. Required fields are marked *