Affinity

Return on Investment

A business is valued, in the market, based on how it performs financially. Management can look at the average cost for an employee and compare that to their peers. If all things are equal, then you will have the competitive edge over your competition if you can keep your costs under that of your competition. The flaw in this thinking is that not all technical folks are equal, and depending on the mix of talent in your company, the productivity can change from group to group. You may be above the curve for cost per unit of work yet your workers are ten times more productive than a similar company who is below the average cost per employee model. When you are trying to fit into the cost model and add the additional resources you are focusing on the metrics rather than efficiencies of operation. The metrics are showing that you need additional resources when what you really need is to become more effective. Thinking you are on the way to solve the problem you may have actually compounded them. You have now added overhead to your organization, with hardware licenses and desks for the new employees. It may result in a large organization that has only a few highly effective employees. This increases the likelihood that you will need to downsize your employee ranks or outsource your jobs to someone who can solve your problems. And this will be increasingly evident by the amount of work you are able to produce with the number of resources you have. The senior management level at most companies watches the numbers very closely. If you are unable to produce within the industry averages, then changes will be made.

Vertical Teams Lack Breadth

Adding to the complexity, as companies get larger they departmentalize and focus their IT resources in one area or another. This means the production folks won’t have any way to know about an application until it actually gets to production. The developers build most applications for development environments and have very little experience in production. This trend alone is creating technologists who are very specialized but have no common knowledge or background in how the system works as a whole. I find this to be the case more and more as I talk to customers. Everyone doesn’t need to be an expert in every area, but having common knowledge on how all the system works together can make a difference to the overall success of the application. This vertical approach to building teams does have a number of advantages in the enterprise. There is the benefit of economies of scale when supporting multiple applications. Generally, there is a fairly decent knowledge-transition plan that must be in place to effectively support the process. The biggest deficit of this approach is that the engineers suffer the most. A number of new specialists do not have a clue of what is going on in the other environments. Yet more and more companies are adopting this model, which means fewer resources are focused on a particular product. This is the ultimate catch-22, trying to determine how to support infrastructure in a cost-effective way while maintaining a high level of technical proficiency.

Production Changes Cost More

During the software development life cycle, the highest cost comes from making code changes after the application has made it to production. The earlier you can catch issues, the cheaper the cost of the software. Having requirement changes in the middle of development causes a huge impact on the budget. Not surprisingly, this is a big reason why projects go over budget and fall behind schedule. Large enterprises spend most of their time developing and designing software; they spend the least amount of time in getting it to production. They concentrate their dollars on what they feel is the core issue—getting the software written. Then they deploy the applications to production and as a result, often have severe issues in production environments. Employees get frustrated and take on the attitude that they can own these issues and solve them or take the approach that it isn’t their problem so someone else will fix it.

For the business application, code is written for the production environment. The challenge we face is that our environments and systems are built in development environments, with production as an afterthought. When a developer or architect does not understand the production domain, he must build to the domain that he does understand, development. Until there is an understanding of how these systems are used, along with the ramification of the design choices, the systems will not improve. It is important to have a good understanding of how the systems are going to be used before development begins. This will enable you to build the right solution and reduce the amount of production changes.

Consequences

If you cannot bring the systems to stability, you will most likely be replaced by someone who can. And if the company deems the system a commodity, the job will be outsourced to the lowest bidder. Large companies with deep pockets are marketing to the executives at your company. They say that they can solve the issues that you have not been able to solve. The choice, in my mind, is simple: You have to do what it takes to get the job done, and you have to make sure the job is right. Failure may be okay for some, for others failure is not an option. (For me, personally, failure is never an option.) And there is no reason to fail when implementing these systems. They may appear to be complex, but it really is a matter of better understanding the relationships or Affinity among the different components. If you are committed to making the necessary changes to increase share value by providing reliable applications, then keep reading. I will define the steps it takes to get the application to a serviceable level. If you are in the middle of a painful implementation or have been part of a failed attempt in the past, you may think this is impossible. You are not alone; those who have had bad experiences also think this is a nearly impossible task. They are so used to the instability of the application that they believe that is how the application was designed. Blame is placed on the companies that built the products, the business owners, the vendors who sell the products, or anyone else they can think of. No matter who is to blame, the consequence for failure of the system is the same, jobs will be lost.

Organizational Challenges

How do you take a company that has been running for so long in a two-tier system and get it up to speed in an n-tier? For that matter, how do you take an existing brick-and-mortar company that finds itself losing market share and help it make the transition to a newly formed company with a competitive Web advantage? Making the transition to a company that has a strong presence and robust systems is not an easy task, but not making that transition will lead to lost revenue and profits for the company. Even if the company chooses to adopt the technology, it may fail, which wastes time and results in losing even more market share. Not only do we have to develop these systems, but they also must be as stable as possible. They must be able to meet business needs and may need to be developed with few or no defined requirements from the business owners. Ideally, when you build a system you would have concrete business requirements so that the company gets what it expects. In many cases, though, the need to compete for newly formed markets cuts down on your thinking time and puts you in survival mode. I have come in to projects where we must quickly adapt and start building before the requirements are in place.

Building and managing systems requires a strong commitment from senior management and determination from middle managers that they want to have systems that are stable and reliable and drive stakeholder value. However, if you do not have support from management; you can still make a difference. It will be up to you to drive the initiatives and do what you can to show progress. It is hard when you have groups of people who are fed up with the application that performs poorly. They may feel as if they have not been properly trained. They may feel that they do not know what they are doing. I know that they do not like being up at all hours of the night with these applications.

Business Transformation

In an effort to compete, there has been a shift from the traditional two-tier systems to the n-tier systems in the enterprise. A two-tier system is composed of two independently written programs that communicate with each other. Until recently, the two-tier was the most prevalent approach to designing and building business systems. It probably is still the most common. The n-tier has a subtle distinction there is no requirement for the components to be installed or deployed on different hardware. Two examples of a two-tier application are printing a document and a point-of-sale system that gathers business data throughout the day and sends it back to the central server that aggregates data. An n-tier application is self-contained, like your online e-mail account. Now, technically, there is a client the Web browser, but for all intents and purposes, the e-mail logic to receive, store, and send e-mail is self-contained on the server.

The n-tier application architectures give a tremendous advantage, such as economies of scale, for the enterprise systems. It also gives a tremendous advantage to the outside world. You can pass along the cost of data entry and many management processes to the consumer or business entity. The business is happy to save the money, and you are happy to have the business at a more affordable cost. It is a win-win situation. Getting to that state, however, is not a simple effort. The companies that adopt these technologies may undergo a rather turbulent shift while learning how to develop and support their new applications. In some cases, these shifts are so dramatic that companies find themselves with an outdated workforce that they need to retrain. At times, they will have duplicated the systems that they are maintaining during the transformation. Companies that choose to revamp their systems have to make extremely difficult decisions in order to make the move. But making the change is important. It gives them the ability to compete in today’s market. Making the shift to the new technologies gives the companies the flexibility they need to reach a worldwide market. So the question becomes not do we move to this new technology, but how do we move to it?

Good technologists who understand the technology can make the transformation go very smoothly. One challenge, however, is that with the newer technologies, there are not as many technologists who have a comprehensive understanding of how all the technologies work together. And even if you do get a good technologist, one may not be enough. The companies that try to transform and have bad experiences often drop these leading-edge programs in favor of a more simple approach to their information systems. And they may try this transition process multiple times before they are successful. Now, more than ever, businesses need to have a focused approach to developing and implementing these complex systems. The businesses that can handle the shifts are finding that they are better able to compete in this information-driven technological age. With businesses becoming more dependent on application servers it is important to know what one is. An application server is a software engine that handles its own business logic and delivers services to a client. It is used for just about anything, from lead generation to customer relationship management (CRM), Web applications, and almost everything in between. Companies depend on these systems to be reliable for their mission-critical applications. The missioncritical applications are now available 24/7. In an online world, that requires companies to continually update and enhance these systems to keep up with the competition. Many of today’s companies use the application server for their critical business needs, including large telecommunications companies, banks, trading firms, energy companies, finance companies, and many more. A minute of downtime may result in hundreds of thousands of unrecoverable dollars. In addition to dollars lost, the perception of the company may also be damaged. Customers expect to be able to log in and take care of business at all hours of the day. The challenge is in learning how to meet that expectation. If your company is unable to maintain its systems and provide the best experience for its customers, then another company certainly will be able to do so.

Environmental Shifts

Companies are striving to cut costs, increase their efficiency, and gain additional market share by exposing their systems to the Internet. Business forces that change the way the business model works now require all of their different technologies to be integrated into one view. This is driving companies to upgrade and integrate their systems or lose the competitive edge. This is where the Java application server is able to add value. It is designed to integrate, to become the glue that holds the enterprise together. The Java application servers are quickly becoming the integration points for all other technologies and the platform of choice for net-new business applications. Requirements for the changes are coming so fast that for businesses to compete, they must develop applications in a matter of months that once took years. The challenge for companies that try to implement them is how to support the systems they currently have while expanding their inventory of new technology.