Seven Practices For A Highly Effective Architecture [bestcomputersprices.blogspot.com]

Seven Practices For A Highly Effective Architecture [bestcomputersprices.blogspot.com]

The all new Milagrow Kupa X11 TabTop PC which has been launched in India sports a rather awkward price tag. A slate running the trial version of Windows 7 Professional is hardly the best excuse for dropping over $ 900 in cold hard cash, especially ... 8 Milagrow Kupa X11 Windows 7 tablet drops into India

INTRODUCTION

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.

THINKING THE BUSINESS, IMPLEMENTING THE TECHNOLOGY (1)

Independent research groups have ide ntified 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 d o 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 actual ly 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

KEEP IT SIMPLER, IF NOT THE SIMPLEST (2)

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

MAKE PRE THOUGHTS AS PRETHOUGHTS (3)

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

BUILD FOR THE CHANGE (4)

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" question s 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?

ALL APPLICATIONS LEAD TO MULTIPLE DEVICES (5)

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. I t 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.

MAKE IT EASY, EVEN IF THAT IS DIFFICULT DOING (6)

Here is the golden rule- "If there is a better way of doing something, time to do it is now". There are two alternatives though, we do it at a higher cost later on or worse someone else does it.

The ease that we are talking about here is not limited to the UI rather it embraces the whole gamut of activities like- deployment, hosting, trouble shooting, integration, self help, encapsulation (exposing only what user needs or should see and hiding the rest) an d so on. Think through about making it all the self evident or at least easy for all the users not limited to the business users, infrastructure, and support teams. Cost involved may not permit implementing them all but it will always point to the direction we should be taking given the constraints.

Given that ease is not just about the UI, it certainly has its share in the pie. Usability is one of the ignored aspects resulting into one or more of the following:

Lot of reworks during the development phase Little acceptance for the application A negative impact on the user productivity Lot many support calls Higher training cost Early retirement of the application

There could be scenarios where a jazzy user interface might be a requirement, e.g., the site selling a multimedia products or an online gaming site. But most of the business applications focus on the capability built into the UI that lets user accomplish their tasks faster, intuitively and makes them more productive. Impressive look is only a secondary requirement for them, more so when it comes at the cost of reduced performance and consumed processing resources. Some tips:

Involve the users while designing the UI and get their sign off on the same Keep the navigation and workflows aligned with the business processes Leverage UI Modeling tools to build the prototype Expect changes and keep room for the same In some cases users might be attached to their older ways and reluctant in adapting what is new even if it helps, it is OK to advocate for the change in those cases Keep the UI decoupled from the business layer so that both can be worked out independently Leverage methodologies for UI development that allows changes in the UI with little efforts Design proactive validations rather reactive (e.g., list box instead of a text box) Provide more than one ways to do the same thing Always give an option to roll-back changes Provide context sensitive help

BUNDLE FOR SALE (7)

Advent of internet, Web Services and Cloud Computing has changed the way the products are priced and sold. Licensing models based on the number of users are soon to be replaced by the activated features and usage based licensing models. Cloud based applications and applications serving to the handheld devices have to follow a different licensing model from a standard client server application. If the application exposes or consumes services it may have to charge for or share the profits. At first glance relationship between the application architecture and the pricing model may seem obscure. But there is a significant relationship nevertheless. The participating applications and services need to capture the information regarding usages and exceptions etc. accurately not only for billing and troubleshooting but also to meet the legal compliances. There could be cases where a vendor fails in making a se ll or to do the sell at a lower cost just because the product didn't support a proper mechanism for enabling-disabling application features. Consider the scenario when business notices that some of the selected capabilities of their flagship product can be actually exposed as services increasing their profits by many folds just to realize that the application can't be made to support capturing the usages information. Or think of the scenario where a hot selling application is asked by a customer to support the mobile devices as well.

Apart from providing the blue print for the application for the as of now technology platform and billing modes architecture should also consider its future as a mobile or cloud supported application that might have to support totally different billing modes.

SUMMARY

A sound architecture is the backbone of any software system. The architects need to learn from the past experiences, both successes and failures, and consider them for their architectures so that it stands the test of the time. This article discussed the following architectural practices that are crucial for the success of the IT systems being developed.

Think in the terms of business while planning the technology implementations Avoid overcomplicating the architecture Give attention to the non functional requirements Implement flexibility considering the change as an inevitable aspect Plan for supporting mobile devices Put efforts to make it convenient for all the user groups Accommodate for the upcoming innovative pricing models Suggest Seven Practices For A Highly Effective Architecture Issues