It is said that variety is the spice of life. It's also how consumers, in other words we as individuals, determine our own, unique approach to our personal productivity, including our choices of the technology we buy and how we use them. It reflects our individuality, the differences that make each us like no one else on the planet. I choose a Motorola RAZR v3, an Apple iPod Touch and a 19" HP laptop. I prefer powering my Griffen Evolve wireless speakers with Pandora. Your choices are undoubtedly different and reflect your values and preferences.
Business have a totally different approach to productivity. As much as possible they want standardization, from vacation policy to the email system. This drives costs down and enables everyone to have an equal playing field. So I have a choice of one laptop or desktop, one Blackberry, one cell phone provider, etc., although choice is limited mainly if I want one or not. This has worked well during the last twenty years when technology has mainly been used only between employees of their own companies. It's also worked well since the rate of technology change needed solely within a business has decreased significantly, so not only are we standard, we're also increasingly out of date.
As businesses have continued to increase leverage to gain further cost reductions, they have had to go outside their four walls to achieve it. This may be a acquisition or an outsourcing contract. This has the consequence of needing to accommodate a greater variety of technologies, which runs counter to cost-effective standardization they've accomplished, and they're not prepared to handle.
Is it any wonder that Internet-based services have begun to dominate the Communications and Collaboration space? You're a Mac, I'm a PC and we both can use that web-based conferencing service, although neither of us could use each others internal service. These services, born to handle the consumer's wide selection of choice, are perfectly positioned to win the heart and dollars of business users.
One way that consumers and business users are alike? They want it now. Game, set and match to the web. Not a fair fight anymore.
Tuesday, August 25, 2009
Thursday, August 20, 2009
70% / 30%
I heard a quote a few weeks back that took me in a far different direction than I'm sure the speaker had intended. "Only thirty percent of an IT budget is typically spent on new capabilities!". I'm sure this was intended to shock us, that so little was being done to help our business and it simply could not be tolerated. But as I dug deeper into this statistic, a very different picture emerged, and one that helps put many of the struggles IT deals with into perspective.
A 70%/30% ratio of maintenance dollars to new capability dollars, at its simplest, means that if your budget is constant, that next year's additional maintenance cost caused by the new capabilities being created is exactly equal to the improved productivity savings in supporting the existing capabilities. If the ratio stays constant, and the budget stays constant, your business can continue to add new capabilities year-in and year-out, forever.
Neat trick. What other segment of your business can boast so loudly. Could you have a house built, add 30% to it each year and have your maintenance bill stay the same? Of course not.
IT has two things going for it, both pulling to make the equation work.
First, Moore's Law has continued to make the hardware cheaper. Mainframe MIPs (Millions of Instructions per Second) were millions of dollars on the 1960's, reduced to thousands of dollars today. Voice calls have been reduced to less than 10% of their previous levels just a decade or so ago. Just a couple of the amazing changes that have occurred along the path of Moore's insight.
Second, IT continues to innovate, bringing a more connected world, fewer inefficiencies and enabling new business models. Without new innovations, the maintenance budget could stay constant, life would be boring and IT demoted to the least important of professions.
If IT can't keep the equation balanced, then something has to give. Either we no longer can afford the new innovations or we spend ever increasing amounts of money on IT. Neither scenario is good for the overall economy or the IT industry. Maintaining, or even improving, on the 70%/30% is an imperative.
So maintenance spend must continue to decrease. Increasing leverage (e.g. virtualization, cloud computing), using cheaper alternatives (e.g. web mail, open source, offshore programmers) and eliminating under-used or redundant services (e.g. portfolio management) are all levers that are being pulled in today's world.
When SAP announced their maintenance cost increase from 17% to 22%, a huge backlash resulted. Why? They dared to increase our maintenance costs, the very side of the IT equation we're working so hard to decrease. But most companies had to grin and bear that cost; the switching cost was far too high, at least in the short-term.
Microsoft, which for many years has delivered valuable new capabilities to our companies, now finds its cash cows predominantly on the maintenance side of the equation. New Windows operating systems and new Office suites are nice, but so what? The action is happening on the Internet, and how many new features can we really use? Unlike SAP, Microsoft's switching costs are relatively low and the alternatives are "good enough".
Given a choice, which one do you think has got to give? Not a trick question.
And the scenario will play out for every maintenance budget item. Do we need that? Is there a cheaper replacement? How can we avoid getting boxed in with vendors, particularly the ones we write the largest checks to? But understanding the underlying, fundamental forces at work here can turn this from a thankless chore to the most important work we can be involved in. We're keeping the innovation engine going strong!
A 70%/30% ratio of maintenance dollars to new capability dollars, at its simplest, means that if your budget is constant, that next year's additional maintenance cost caused by the new capabilities being created is exactly equal to the improved productivity savings in supporting the existing capabilities. If the ratio stays constant, and the budget stays constant, your business can continue to add new capabilities year-in and year-out, forever.
Neat trick. What other segment of your business can boast so loudly. Could you have a house built, add 30% to it each year and have your maintenance bill stay the same? Of course not.
IT has two things going for it, both pulling to make the equation work.
First, Moore's Law has continued to make the hardware cheaper. Mainframe MIPs (Millions of Instructions per Second) were millions of dollars on the 1960's, reduced to thousands of dollars today. Voice calls have been reduced to less than 10% of their previous levels just a decade or so ago. Just a couple of the amazing changes that have occurred along the path of Moore's insight.
Second, IT continues to innovate, bringing a more connected world, fewer inefficiencies and enabling new business models. Without new innovations, the maintenance budget could stay constant, life would be boring and IT demoted to the least important of professions.
If IT can't keep the equation balanced, then something has to give. Either we no longer can afford the new innovations or we spend ever increasing amounts of money on IT. Neither scenario is good for the overall economy or the IT industry. Maintaining, or even improving, on the 70%/30% is an imperative.
So maintenance spend must continue to decrease. Increasing leverage (e.g. virtualization, cloud computing), using cheaper alternatives (e.g. web mail, open source, offshore programmers) and eliminating under-used or redundant services (e.g. portfolio management) are all levers that are being pulled in today's world.
When SAP announced their maintenance cost increase from 17% to 22%, a huge backlash resulted. Why? They dared to increase our maintenance costs, the very side of the IT equation we're working so hard to decrease. But most companies had to grin and bear that cost; the switching cost was far too high, at least in the short-term.
Microsoft, which for many years has delivered valuable new capabilities to our companies, now finds its cash cows predominantly on the maintenance side of the equation. New Windows operating systems and new Office suites are nice, but so what? The action is happening on the Internet, and how many new features can we really use? Unlike SAP, Microsoft's switching costs are relatively low and the alternatives are "good enough".
Given a choice, which one do you think has got to give? Not a trick question.
And the scenario will play out for every maintenance budget item. Do we need that? Is there a cheaper replacement? How can we avoid getting boxed in with vendors, particularly the ones we write the largest checks to? But understanding the underlying, fundamental forces at work here can turn this from a thankless chore to the most important work we can be involved in. We're keeping the innovation engine going strong!
Monday, June 22, 2009
Five Levels of Support
Those of us in the computer field are resigned to at least the occasional support role. If you're in the office next to the CIO, you might just want to consider it hazard duty.
But support comes in many flavors, as I'll attempt to explain these five level of support in more detail:
"support", or "little-s support", occurs when someone else, like it or not, has Support, but needs your help and assistance to resolve a problem. An application developer might need some help from a performance management expert or a network trace run to diagnose an issue. Care must be taken to avoid ending up with Support in these instances.
Fsupport, or "F-support", is familiar to those of us that provide computer support for Friends and Family, the "F" becoming clear. Since Friends certainly occur in the workplace, some confusion can arise when you offer "above and beyond" service for maybe no apparent reason. Maybe you're local expert that your colleagues would rather pull into a problem than call the Help Desk. This can become a balancing act and care must be taken to pick your Friends wisely.
Xsupport, or "X-support", is easily recognized by anyone that studies organization charts. At a certain level an eXecutive, the "X" becoming clear, gets support and loving attention regardless of corporate policy, their love of non-standard computing equipment and any resemblance of a cost/benefit analysis. Need to help their spouse with that new iMac at their summer home, no problem. Just be nice and all will pass by without a career threatening cloud over your head.
That leaves us with FYBYOYO, phonetically "fib-YO-YO", that stands for "Forget You Buddy, You're On Your Own", at least in polite company. This is probably the least familiar of the five levels of support, probably because it appears in real life with the same frequency as blue M&Ms. Whether it's our love of being heroes, racking up a few markers to be called in later, not wanting to rock the boat or a truly altruistic nature, FYBYOYO is a hard stance to take. But if you're tempted, make sure to you're clear about the first four levels. They might trump you more often than you think.
But support comes in many flavors, as I'll attempt to explain these five level of support in more detail:
- Support
- support
- Fsupport
- Xsupport
- FYBYOYO
"support", or "little-s support", occurs when someone else, like it or not, has Support, but needs your help and assistance to resolve a problem. An application developer might need some help from a performance management expert or a network trace run to diagnose an issue. Care must be taken to avoid ending up with Support in these instances.
Fsupport, or "F-support", is familiar to those of us that provide computer support for Friends and Family, the "F" becoming clear. Since Friends certainly occur in the workplace, some confusion can arise when you offer "above and beyond" service for maybe no apparent reason. Maybe you're local expert that your colleagues would rather pull into a problem than call the Help Desk. This can become a balancing act and care must be taken to pick your Friends wisely.
Xsupport, or "X-support", is easily recognized by anyone that studies organization charts. At a certain level an eXecutive, the "X" becoming clear, gets support and loving attention regardless of corporate policy, their love of non-standard computing equipment and any resemblance of a cost/benefit analysis. Need to help their spouse with that new iMac at their summer home, no problem. Just be nice and all will pass by without a career threatening cloud over your head.
That leaves us with FYBYOYO, phonetically "fib-YO-YO", that stands for "Forget You Buddy, You're On Your Own", at least in polite company. This is probably the least familiar of the five levels of support, probably because it appears in real life with the same frequency as blue M&Ms. Whether it's our love of being heroes, racking up a few markers to be called in later, not wanting to rock the boat or a truly altruistic nature, FYBYOYO is a hard stance to take. But if you're tempted, make sure to you're clear about the first four levels. They might trump you more often than you think.
Monday, June 8, 2009
Losing Twenty Percent
Information technologists live in interesting times. The Internet continues to bring the platforms and services that mostly eliminate the problems inherent in the PC-based client/server era, such as large upfront capital investments, slow deployment of new or changed services and a daunting set of security issues rooted in its birth as a non-shared technology (i.e. DOS PCs with a dinky floppy drive and molasses-slow modems) attempting to thrive in the interconnected world of email, web-based services and ever-increasing bandwidths. While using the Internet has its own scale issues, it's clear to everyone from the board room to the kid's bedroom that PC knowledge is moving down in value, and knowledge of the Internet is moving up.
Dealing with change is hardly unique to IT people, but perhaps it's the constant, year-in, year-out bombardment of change that is not as prevalent in other fields. The way I've described it to people I've been fortunate enough to work with is to set their expectation, and my own, that twenty percent of the value of their current skill set is lost every year. Just to stay even requires learning a new twenty percent each year. This obviously is an estimate, varies from person to person and is greater in some years and less in others. But overall it's not far off and the point is not precision, it's direction. Stay still for long and your risk of being obsolete gets higher and the effort to retrain to an entire new skill set becomes tougher.
A technology leader must work with each and every person to insure that this does not happen. They must provide the constant push required to change their people, and the education, projects and rewards to pull them forward. It's easier to let people stay in a job and avoid the short-term productivity hit. It's easier to let someone convince you that they're happy where they are and avoid the whining. But it's harder to change attitudes baked in over years of stagnation and retrain, for example, a mainframe COBOL programmer in Java, C++ or Ruby. If they're lucky enough to time their retirement to their obsolescence, they're in the fortunate few. Most take jobs in less demanding parts of IT or leave the field entirely.
One of the most effective methods of gaining people's attention is to purposely, publicly and continually eliminate older technologies. That elimination may take the form of outsourcing the old mainframe systems, replacing dial-up modem banks with an Internet ISP or manual PC software installation with an automated system. This is, by far, not the only benefit you'll gain from this, but emphasizing the constant "out with the old, in with the new" mantra will send strong signals throughout the organization.
Change can be overwhelming to people, particularly ones that are large or arrive as surprises. The previous suggestions deal with the surprises, but what can be done to keep change in manageable chunks? Fortunately, that's where the twenty percent comes in handy. It's not that large if handled on a continual basis. But a totally new twenty percent is much more difficult than one that is somewhat familiar. Asking a programmer that knows several languages to add Ruby to that list is nowhere near as difficult as asking them to configure routers. Asking a network analyst to configure firewalls is probably better than asking them to learn a programming language.
While keeping within one's area and learning new skills is a good tactic, the people that are very valuable have skills in many areas, ready to pitch in on just about any project that comes around. Some people seem naturally born or gifted to play in all areas, or maybe they just get bored more easily. Regardless, your organization needs to move people around departments and the earlier they learn this the better.
Dealing with change is hardly unique to IT people, but perhaps it's the constant, year-in, year-out bombardment of change that is not as prevalent in other fields. The way I've described it to people I've been fortunate enough to work with is to set their expectation, and my own, that twenty percent of the value of their current skill set is lost every year. Just to stay even requires learning a new twenty percent each year. This obviously is an estimate, varies from person to person and is greater in some years and less in others. But overall it's not far off and the point is not precision, it's direction. Stay still for long and your risk of being obsolete gets higher and the effort to retrain to an entire new skill set becomes tougher.
A technology leader must work with each and every person to insure that this does not happen. They must provide the constant push required to change their people, and the education, projects and rewards to pull them forward. It's easier to let people stay in a job and avoid the short-term productivity hit. It's easier to let someone convince you that they're happy where they are and avoid the whining. But it's harder to change attitudes baked in over years of stagnation and retrain, for example, a mainframe COBOL programmer in Java, C++ or Ruby. If they're lucky enough to time their retirement to their obsolescence, they're in the fortunate few. Most take jobs in less demanding parts of IT or leave the field entirely.
One of the most effective methods of gaining people's attention is to purposely, publicly and continually eliminate older technologies. That elimination may take the form of outsourcing the old mainframe systems, replacing dial-up modem banks with an Internet ISP or manual PC software installation with an automated system. This is, by far, not the only benefit you'll gain from this, but emphasizing the constant "out with the old, in with the new" mantra will send strong signals throughout the organization.
Change can be overwhelming to people, particularly ones that are large or arrive as surprises. The previous suggestions deal with the surprises, but what can be done to keep change in manageable chunks? Fortunately, that's where the twenty percent comes in handy. It's not that large if handled on a continual basis. But a totally new twenty percent is much more difficult than one that is somewhat familiar. Asking a programmer that knows several languages to add Ruby to that list is nowhere near as difficult as asking them to configure routers. Asking a network analyst to configure firewalls is probably better than asking them to learn a programming language.
While keeping within one's area and learning new skills is a good tactic, the people that are very valuable have skills in many areas, ready to pitch in on just about any project that comes around. Some people seem naturally born or gifted to play in all areas, or maybe they just get bored more easily. Regardless, your organization needs to move people around departments and the earlier they learn this the better.
Sunday, April 5, 2009
Applying Data Center Recovery Principles to PCs
PCs have become an operational lifeblood of most organizations and the amount of viruses, malware and zero-day attacks continues to increase. Very large security practices have been built up to address these problems and yet this trend surges forward unabated. Are we simply stuck with continually paying more to protect our systems or is there a point where PCs are treated in the same manner as the servers in the data center?
Large companies installed mainframes in the 1960s to automate back office processes, gain efficiencies and enable new and larger business models. It soon became apparent that the data center needed to be well protected. Guards, keypass entry cards, UPS power and fire suppression systems became the norm. But investments to keep the data center safe were not enough and the disaster recovery business was created to allow a company, at a fraction of the cost of running a duplicate data center, to recover their critical applications if the primary data center was unusable. You could never spend enough money to reduce the risk of losing the primary data center to zero.
Perhaps applying the same principles to recovering access to these same applications in the advent of a massive virus outbreak, power blackout or communications failure would provide a cost-effective solution. These applications might also be the same ones that employees need while working remotely.
There are many ways to architect and design a solution, but the least common denominator in today's world is the web browser. If you're fortunate enough to have all your applications web-enabled, then you have a huge head start. Perhaps a dual-boot option on your corporate PCs with a Linux/Firefox option is enough to get your users productive again. Another strategy would be to have employees use their home computers, almost ubiquitous now, as their backup device. A final option would be to re-stage each PC, although this may take more time to accomplish than the business might be able to tolerate.
For those not fortunate enough to be fully web-enabled, which includes most of us, a solution to access those applications needs to be available, but not require a huge investment in hardware and software. The advent of pay-as-you-go Cloud Computing and more robust Open Source software comes to the rescue. The idea is to build a ready-to-go desktop image in the Cloud (e.g. Amazon Web Services) using Linux, Firefox, native Linux applications and Windows applications under the Wine environment. This image would have the necessary VPN connectivity to your data center to access the back-end services. Each user would spin up a copy of the image, with proper authentication of course, and be back in business in minutes. Or perhaps leveraging open source virtualization software can allow multiple people to use one Cloud server concurrently.
This image might also be used for home or hotel access, and potentially avoid the extra costs of providing laptops by leveraging personal and hotel business-center PCs. A copy of this image that provides isolated access during your disaster recovery testing can significantly reduce that network effort. These are just a few of the possible uses for a solution architected in this manner.
Large companies installed mainframes in the 1960s to automate back office processes, gain efficiencies and enable new and larger business models. It soon became apparent that the data center needed to be well protected. Guards, keypass entry cards, UPS power and fire suppression systems became the norm. But investments to keep the data center safe were not enough and the disaster recovery business was created to allow a company, at a fraction of the cost of running a duplicate data center, to recover their critical applications if the primary data center was unusable. You could never spend enough money to reduce the risk of losing the primary data center to zero.
Perhaps applying the same principles to recovering access to these same applications in the advent of a massive virus outbreak, power blackout or communications failure would provide a cost-effective solution. These applications might also be the same ones that employees need while working remotely.
There are many ways to architect and design a solution, but the least common denominator in today's world is the web browser. If you're fortunate enough to have all your applications web-enabled, then you have a huge head start. Perhaps a dual-boot option on your corporate PCs with a Linux/Firefox option is enough to get your users productive again. Another strategy would be to have employees use their home computers, almost ubiquitous now, as their backup device. A final option would be to re-stage each PC, although this may take more time to accomplish than the business might be able to tolerate.
For those not fortunate enough to be fully web-enabled, which includes most of us, a solution to access those applications needs to be available, but not require a huge investment in hardware and software. The advent of pay-as-you-go Cloud Computing and more robust Open Source software comes to the rescue. The idea is to build a ready-to-go desktop image in the Cloud (e.g. Amazon Web Services) using Linux, Firefox, native Linux applications and Windows applications under the Wine environment. This image would have the necessary VPN connectivity to your data center to access the back-end services. Each user would spin up a copy of the image, with proper authentication of course, and be back in business in minutes. Or perhaps leveraging open source virtualization software can allow multiple people to use one Cloud server concurrently.
This image might also be used for home or hotel access, and potentially avoid the extra costs of providing laptops by leveraging personal and hotel business-center PCs. A copy of this image that provides isolated access during your disaster recovery testing can significantly reduce that network effort. These are just a few of the possible uses for a solution architected in this manner.
Monday, March 23, 2009
Who Has A Bigger Problem
Your manager has just assigned you a difficult project or problem and you're at a loss to envision any possible solution. Is it time to hit the pervasive search engine and starting looking? Perhaps a call to a favorite vendor or perhaps an unknown one? An approach might be to stop looking for a solution and find someone that has a bigger problem than you do, preferably a much larger problem. Depending on the problem, you might even find that person inside your own company.
Odds are someone has a bigger problem than you do and looking outside your normal field of vision is often needed. Looking to reduce the cost of your email system? Try an organization such as a university, other large not-for-profit corporation or a particularly financially distressed company for ideas. Want to improve the integrity of your data center? Can you find a company where revenue dead stops when they're down. How about the stock market? If they make the Wall Street Journal headlines when problems occur, that's a good place to start.
Money, or lack thereof, is a good place to start hunting. Following the money trail is also useful. Are you looking for management support for a new security idea and the CIO isn't very receptive? Who else in your organization is rewarded when incidents are reduced or eliminated? With the advent of SOX compliance putting more people on the chopping block for deficiencies, perhaps Audit, Compliance or the CFO has that bigger problem.
Sales people are rarely a good source, simply because they sell a solution to your problem, not to their problem. Their problem is making their quota, and rightfully so. Helping solve your problem may be aligned at times, but in most cases they sell stuff, not solutions, and their reward is not directly tied to your problem being solved, but in getting the contract signed. Sales people can be a good conduit into making connections into the companies you want to investigate. A better way is to join and be active in one or two few large user groups or leverage a company subscription to The Hackett Group, Gartner Group or other advisory and benchmarking firms. Using LinkedIn, Plaxo or other web-based social networks can also lead to making the right contact.
The idea is not just to implement everything another company does, but to generate new insights into your specific problem. Perhaps one or two components of their solution is enough to satisfy your current needs. Stretching your mind in the direction of the problem, not an immediate solution, may be the key to your next "breakthrough".
Odds are someone has a bigger problem than you do and looking outside your normal field of vision is often needed. Looking to reduce the cost of your email system? Try an organization such as a university, other large not-for-profit corporation or a particularly financially distressed company for ideas. Want to improve the integrity of your data center? Can you find a company where revenue dead stops when they're down. How about the stock market? If they make the Wall Street Journal headlines when problems occur, that's a good place to start.
Money, or lack thereof, is a good place to start hunting. Following the money trail is also useful. Are you looking for management support for a new security idea and the CIO isn't very receptive? Who else in your organization is rewarded when incidents are reduced or eliminated? With the advent of SOX compliance putting more people on the chopping block for deficiencies, perhaps Audit, Compliance or the CFO has that bigger problem.
Sales people are rarely a good source, simply because they sell a solution to your problem, not to their problem. Their problem is making their quota, and rightfully so. Helping solve your problem may be aligned at times, but in most cases they sell stuff, not solutions, and their reward is not directly tied to your problem being solved, but in getting the contract signed. Sales people can be a good conduit into making connections into the companies you want to investigate. A better way is to join and be active in one or two few large user groups or leverage a company subscription to The Hackett Group, Gartner Group or other advisory and benchmarking firms. Using LinkedIn, Plaxo or other web-based social networks can also lead to making the right contact.
The idea is not just to implement everything another company does, but to generate new insights into your specific problem. Perhaps one or two components of their solution is enough to satisfy your current needs. Stretching your mind in the direction of the problem, not an immediate solution, may be the key to your next "breakthrough".
Tuesday, March 10, 2009
Integration Architecture
When architecting a solution to integrate two systems, it's useful to realize that only three categories are possible. Applying the correct approach is crucial to avoiding extra coding, operational issues and higher costs. The three categories are:
- Batch - A set of requests will be processed together at regular intervals. This is typically done to process requests more efficiently or during a window when resources are more available. This is a time-based mechanism.
- Asynchronous - A response to a request is needed as soon as possible. The data will be delivered when the other side is ready and will never be lost. This is an event-based trigger mechanism.
- Real-Time - A response to a request is required in real-time. In case the request is not fulfilled within a reasonable amount of time, the data will be discarded.
Batch interfaces have been around since the advent of mainframes and punch cards. A single method to handle batch data exchange should be used throughout the data center to simplify all operational aspects from security to recovery. One folder structure could be developed for all Production data and a second for Test data. These folders should be mountable to all systems, so multiple protocols (e.g. NFS, SMB) may be required. File system renaming is a useful practice to keep in-flight work from causing issues. As an example, perhaps we have a folder named Payroll. Within the Payroll folder, we create an Inbound, Ready, InProcess, Processed and Error folders. Data being created is put in the Inbound folder and when complete is renamed to put it in the Ready folder. A batch job runs looks in the Ready folder, renames it to put it in the InProcess folder and renames it again upon successful completion to the Processed folder or to the Error folder if unsuccessful. This simple example may not be enough for your requirements, so expand the concept with as many folders and subfolders needed.
Asynchronous interfaces are typically built upon a messaging queuing infrastructure using products such as Microsoft's MSMQ or IBM's MQSeries. Like Batch, you should establish only one method for this type of exchange. Asynchronous interfaces are typically used to process data that needs very quick turnaround, but the data can't be lost if the target system is unavailable.
There are a number of reasons that individual transactions can fail, special attention needs to be paid to build a notification system with the needed data available to take quick action to resolve the error. An approach to this is to make a copy of any transaction that fails and put it into a message queue where a program will read that data, send the appropriate notifications and make the data and error code available to the person performing the troubleshooting. A method of "replaying" the transaction by putting the transaction back on its original queue is useful to avoid manually performing each failed transaction.
Real-time interfaces come in lots of shapes and sizes and will vary from one vendor to the next. Standardization is coming slowly with the adoption of web standards, so you're likely stuck with supporting a variety of proprietary and open standards, fortunately in most cases with the aid of the vendor who knows their own choices well. Still, it will cause a great deal of operational support issues and these interfaces will tend to be your most critical. Put together a team to attack these issues before they become a business issue.
Your standards can be drawn using a generic Source System and Target System on either side of a diagram and your Real-Time, Asynchronous and Batch solutions connecting the two Systems. Each of the three paths describe the specific hardware and software that is standard in your environment. The simple diagram can then be expanded with the specific details for a particular set of Systems.
A few number of highly reusable components will speed the delivery of your interfaces at a greatly reduced cost, and most important, with the least amount of operational issues and business impact.
Subscribe to:
Posts (Atom)