Essence Of Information Technology Landscape In Business Organizations

Any manufacturing organization would ideally have its Vision and Mission to guide them through its future course.

But does the organization have an Information Technology vision in place. Some organization may question this need, they may feel that the organizational focus should be on its core competency and Information Technology just plays a role of an enabler. But on the contrary such organizations are in greater need of an Information Technology vision. The role of Information Technology is that of a business driver in today’s competitive environment and not just an enabler.

Now lets analyse the need and essence of Information Technology Landscape for a business organization.

Consider an XYZ organization, which after half a decade of existence had entered a phase of business growth. Till date the role of Information Technology would have been that of a support system. My experience says that most of the organizations in such a scenario tend to focus on their core competency and grabbing more business opportunities, and almost no attention is given to the key role Information Technology can play.

Keeping in mind the type of competition and constraints the business organization faces, like for example high demand and need for rapid increase in manufacturing capabilities, need of sizeable investments to enter new markets or more focus for business tie ups, its apparently difficult to focus and believe that Information Technology can be a business driver. But the fact of the matter is, it really is. So the question is how can it be done?

The organization requirements can be divided majorly into functional requirements (very specific to the industry domain), routine transactional requirements, content management requirements, workflow requirements and Infrastructural requirements.

Now the organization has to have an Information Technology Landscape plan, based on its current and future business landscape.

There can be phase wise implementation of the Information Technology landscape plan. Start with covering the domain functionalities (R&D, F&D etc), the benefits would be evident in this case. Followed by transactional systems (like ERP) and then content management systems. The benefits of such systems will be realized over a period of time, ideally after the stabilization period.

For workflow systems, they have to be built at an enterprise level. These workflow systems are of critical importance to an organization. The effectiveness of above systems can be greatly hampered by an inefficient workflow system in place.

Information Technology infrastructure is an on going process in an Information Technology landscape implementation. Any effective technology solution would have to be right collaboration of business software applications and hardware infrastructure.

The most critical of all is to always have an Integration Route, which the Information Technology landscape implementation strategy would follow. This well planned Integration Route is required for a holistic Information Technology perspective.

Gradually as the Information Technology landscape builds up in the organization, there will corresponding benefits in terms of business process automation, business process management, and finally leading to effective knowledge management with in the organization. In such a scenario, the Information Technology acts as a business driver; there onwards Information Technology perspective will be part of any future organizational strategy in scaling business growth.

Information Systems Theory 101

“The first on-line, real-time, interactive, data base system was double-entry bookkeeping which was developed by the merchants of Venice in 1200 A.D.”

– Bryce’s Law

Systems work is not as hard as you might think. However, we have a tendency in this business to complicate things by changing the vocabulary of systems work and introducing convoluted concepts and techniques, all of which makes it difficult to produce systems in a consistent manner. Consequently, there is a tendency to reinvent the wheel with each systems development project. I believe I owe it to my predecessors and the industry overall to describe basic systems theory, so that people can find the common ground needed to communicate and work. Fortunately, there are only four easy, yet important, concepts to grasp which I will try to define as succinctly as possible.

1. THERE ARE THREE INHERENT PROPERTIES TO ANY SYSTEM

Regardless of the type of system, be it an irrigation system, a communications relay system, an information system, or whatever, all systems have three basic properties:

A. A system has a purpose – such as to distribute water to plant life, bouncing a communications signal around the country to consumers, or producing information for people to use in conducting business.

B. A system is a grouping of two or more components which are held together through some common and cohesive bond. The bond may be water as in the irrigation system, a microwave signal as used in communications, or, as we will see, data in an information system.

C. A system operates routinely and, as such, it is predictable in terms of how it works and what it will produce.

All systems embrace these simple properties. Without any one of them, it is, by definition, not a system.

For our purposes, the remainder of this paper will focus on “information systems” as this is what we are normally trying to produce for business. In other words, the development of an orderly arrangement or grouping of components dedicated to producing information to support the actions and decisions of a particular business. Information Systems are used to pay employees, manage finances, manufacture products, monitor and control production, forecast trends, process customer orders, etc.

If the intent of the system is to produce information, we should have a good understanding of what it is…

2. INFORMATION = DATA + PROCESSING

Information is not synonymous with data. Data is the raw material needed to produce information. Data by itself is meaningless. It is simply a single element used to identify, describe or quantify an object used in a business, such as a product, an order, an employee, a purchase, a shipment, etc. A data element can also be generated based on a formula as used in a calculation; for example:

Net-Pay = Gross-Pay – FICA – Insurance – City-Tax – Union-Dues – (etc.)

Only when data is presented in a specific arrangement for use by the human being does it become information. If the human being cannot act on it or base a decision from it, it is nothing more than raw data. This implies data is stored, and information is produced. It is also dependent on the wants and needs of the human being (the consumer of information). Information, therefore, can be defined as “the intelligence or insight gained from the processing and/or analysis of data.”

The other variable in our formula is “processing” which specifies how data is to be collected, as well as its retrieval in order to produce information. This is ultimately driven by when the human being needs to make certain actions and decisions. Information is not always needed “upon request” (aka “on demand”); sometimes it is needed once daily, weekly, monthly, quarterly, annually, etc. These timing nuances will ultimately dictate how data is collected, stored, and retrieved. To illustrate, assume we collect data once a week. No matter how many times during the week we make a query of the data base, the data will only be valid as of the last weekly update. In other words, we will see the same results every day for one week. However, if we were to collect the data more frequently, such as periodically throughout the day, our query will produce different results throughout the week.

Our formula of “I = D + P” makes an important point: if the data is changed, yet the processing remains the same, the information will change. Conversely, if the data remains the same, yet the processing changes, the information will also change. This leads to a compelling argument to manage data and processing as separate by equal resources which can be manipulated and reused to produce information as needed.

3. SYSTEMS ARE LOGICAL IN NATURE AND CAN BE PHYSICALLY IMPLEMENTED MANY DIFFERENT WAYS

An information system is a collection of processes (aka, “sub-systems”) to either collect and store data, to retrieve data and produce information, or a combination of both. The cohesive bond between these components is the data which should be shared and reused throughout the system (as well as other systems). You will observe we have not yet discussed the most suitable way to physically implement the processes, such as through the use of manual processes, computer programs, or other office technology. In other words, at this stage, the sub-systems of the system simply define logically WHAT data must be processed, WHEN it must be processed, and who will consume the information (aka “end-users”), but it most definitely does not specify HOW the sub-system is to be implemented.

Following this, developers determine a suitable approach for physically implementing each sub-system. This decision should ultimately be based on practicality and cost effectiveness. Sub-systems can be implemented using manual procedures, computer procedures (software), office automation procedures, or combinations of all three. Depending on the complexity of the sub-system, several procedures may be involved. Regardless of the procedures selected, developers must establish the precedent relationships in the execution of the procedures, either sequentially, iteratively, of choice (thereby allowing divergent paths). By defining the procedures in this manner, from start to end, the developers are defining the “work flow” of the sub-system, which specifies HOW the data will be physically processed (including how it is to be created, updated, or referenced).

Defining information systems logically is beneficial for two reasons:

* It provides for the consideration of alternative physical implementations. How one developer designs it may very well be different than the next developer. It also provides the means to effectively determine how a purchased software package may satisfy the needs. Again, the decision to select a specific implementation should be based on practicality and cost justification.

* It provides independence from physical equipment, thereby simplifying the migration to a new computer platform. It also opens the door for system portability, for example; our consulting firm helped a large Fortune 500 conglomerate design a single logical payroll system which was implemented on at least three different computer platforms as used by their various operating units; although they physically worked differently, it was all the same basic system producing the same information.

These logical and physical considerations leads to our final concept…

4. A SYSTEM IS A PRODUCT THAT CAN BE ENGINEERED AND MANUFACTURED LIKE ANY OTHER PRODUCT.

An information system can be depicted as a four level hierarchy (aka, “standard system structure”):

LEVEL 1 – System

LEVEL 2 – Sub-systems (aka “business processes”) – 2 or more

LEVEL 3 – Procedures (manual, computer, office automation) – 1 or more for each sub-system

LEVEL 4 – Programs (for computer procedures), and Steps (for all others) – 1 or more for each procedure

Each level represents a different level of abstraction of the system, from general to specific (aka, “Stepwise Refinement” as found in blueprinting). This means design is a top-down effort. As designers move down the hierarchy, they finalize design decisions. So much so, by the time they finish designing Level 4 for a computer procedure, they should be ready to write program source code based on thorough specifications, thereby taking the guesswork out of programming.

The hierarchical structure of an information system is essentially no different than any other common product; to illustrate:

LEVEL 1 – Product

LEVEL 2 – Assembly – 2 or more

LEVEL 3 – Sub-assembly – 1 or more for each assembly

LEVEL 4 – Operation – 1 or more for each sub-assembly

Again, the product is designed top-down and assembled bottom-up (as found in assembly lines). This process is commonly referred to as design by “explosion” (top-down), and implementation by “implosion” (bottom-up). An information system is no different in that it is designed top-down, and tested and installed bottom-up. In engineering terms, this concept of a system/product is commonly referred to as a “four level bill of materials” where the various components of the system/product are defined and related to each other in various levels of abstraction (from general to specific).

This approach also suggests parallel development. After the system has been designed into sub-systems, separate teams of developers can independently design the sub-systems into procedures, programs, and steps. This is made possible by the fact that all of the data requirements were identified as the system was logically subdivided into sub-systems. Data is the cohesive bond that holds the system together. From an engineering/manufacturing perspective it is the “parts” used in the “product.” As such, management of the data should be relegated to a separate group of people to control in the same manner as a “materials management” function (inventory) in a manufacturing company. This is commonly referred to as “data resource management.”

This process allows parallel development, which is a more effective use of human resources on project work as opposed to the bottleneck of a sequential development process. Whole sections of the system (sub-systems) can be tested and delivered before others, and, because data is being managed separately, we have the assurance it will all fit together cohesively in the end.

The standard system structure is also useful from a Project Management perspective. First, it is used to determine the Work Breakdown Structure (WBS) for a project complete with precedent relationships. The project network is then used to estimate and schedule the project in part and in full. For example, each sub-system can be separately priced and scheduled, thereby giving the project sponsors the ability to pick and chose which parts of the system they want early in the project.

The standard system structure also simplifies implementing modification/improvements to the system. Instead of redesigning and reconstructing whole systems, sections of the system hierarchy can be identified and redesigned, thereby saving considerable time and money.

This analogy between a system and a product is highly credible and truly remarkable. Here we can take a time-proven concept derived from engineering and manufacturing and apply it to the design and development of something much less tangible, namely, information systems.

CONCLUSION

Well, that’s it, the four cardinal concepts of Information Systems theory. I have deliberately tried to keep this dissertation concise and to the point. I have also avoided the introduction of any cryptic vocabulary, thereby demonstrating that systems theory can be easily explained and taught so that anyone can understand and implement it.

Systems theory need not be any more complicated than it truly is.

The Business Case for Information Security: Getting Your Security Budget Approved

Information systems security is very vital in enterprises today, in order to curb the numerous cyber threats against information assets. Despite the good arguments that are put up by Information security managers, the Board and Senior Management in Organizations, might still drag their feet, to approve information security budgets, visa vi other items, like marketing and promotion, which they believe have greater Return on Investment (ROI). How do you then, as a Chief Information Security O fficer (CISO)/IT /Information Systems manager, convince Management or the Board of the need to invest in Information security?

I once had a conversation with an IT Manager for one of the big regional financial institutions, who shared his experience on getting an information security budget approved. The IT department was tussling it out with Marketing for some funds that had been made available from savings on the annual budget. ” You see, if we invest in this marketing campaign, not only shall the targeted market segment help us make and surpass the numbers, but also estimates show that we could more than double our loan portfolio.” argued the marketing people. On the other hand, IT’s argument was that “By being proactive in procuring a more robust Intrusion prevention System (IPS), they will be reduction in security incidents”. Management decided to allocate the extra funds to Marketing. The IT people wondered then, what they had done wrong, that the marketing people got right! So how do you ensure that you get that budget approval for your Information security project?

It’s vital for management to appreciate the consequences of inaction as far as securing the Enterprise is concerned, if a breach occurred not only will the organization su ffer from loss of reputation and customers, due to reduced confi dence in the brand, but also a breach could lead to loss of revenue and even legal action being taken against the organization, situations in which good marketing campaigns might fail to redeem your organization.

We try to address the major points management could raise against investing in information security.

1. Information security solutions tend to be costly, where are the tangible returns?

The overall goal of any organization is to create / add value for the shareholders or stakeholders. Can you quantify the bene fits of the countermeasure you want to procure? What indicators are you employing to justify that investment in information security? Does your argument for a countermeasure align with the overall objectives of the Organization, how do you justify that your action will help the organization achieve its goals and increase shareholders/stake holder’s value. For example, if the organization has prioritized customer acquisition and customer retention, how does procurement of the information security solution you propose, help achieve that goal?

2. Isn’t the countermeasure a panic / isolated reaction to a regulatory requirement or recent audit query?

The vast majority of Information security projects could be driven by external regulations or compliance requirements, or could be as a reaction to a recent query by the external auditors or even as a result of a recent systems breach. For example, a financial regulator could require that all financial institutions implement an IT Vulnerability assessment tool. Thus, the organization is required to comply at any cost or face penalties. While response to these regulatory requirements is necessary, just plugging the holes and ” fighting the fires” approach are not sustainable. The implementation of process change in isolation could result into an environment of working in silos, conflicting information and terminology, disparate technology, and a lack of connection to business strategy. [1]

Uncoordinated reactions to specific regulatory requirements, may lead to implementing solutions that are not aligned with the business strategy of the organization. Therefore to overcome this problem and get funding approval and management support, your argument and business case should show how the solutions you intend to procure fit into the bigger picture, and how this aligns with the overall objective of securing assets in the organization.

What are the costs, implications, and the impact of doing nothing?

You will need to communicate to management, the basic business value of the solution you want to procure. You will start by showing/ calculating the current cost, implications, and the impact of doing nothing; if the countermeasure you want to procure is not in place. You could classify these as:

Direct cost – the cost that the organization incurs for not having the solution in place.

Indirect cost – the amount of time, effort and other organizational resources that could be wasted.

Opportunity cost – the cost resulting from lost business opportunities, if the security solution or service you propose was not in place and how that could impact the organization’s reputation and goodwill.

You could use the following pointers and expound on these further:

• What regulatory fines due to non-compliance, does the organization face?

• What is the impact of business interruption and productivity losses?

• How will the organization be impacted, her brand or reputation that could result in huge financial losses?

• What losses are incurred due to poor management of business risk?

• What losses do we face attributed to fraud: external or internal?

• What are the costs spent on people involved in mitigating risks that would otherwise be reduced by deploying the countermeasure?

• How will loss of Data, which is a great business asset, impact our operations and what is the actual cost of recovering from such a disaster?.

• What is the legal implication of any breach as a result of our non-action?

How does the proposed solution reduce cost and increase business value.

You will then need to show how the countermeasure you propose is going to reduce cost and increase business value. Again you could expound more on the following areas:

• Show how increased efficiencies and productivity, of deploying the countermeasure will benefit the organization.

• Quantify how reduced downtime will increase business productivity.

• Show how being proactive could reduce on IT Audit & Assessment costs.

• Quantify the cost reduction that would otherwise be associated with internal audits, third-party audits, and technology.

According to a 2011 research conducted by the Ponemon Institute and Tripwire, Inc., it was found that Business disruption and productivity losses are the most expensive consequences of non-compliance. On average, non-compliance cost is 2.65 times the cost of compliance for the 46 organizations that were sampled. With the exception of two cases, non-compliance cost exceeded compliance cost.[2]. Meaning that, investing is information security in order to protect information assets and comply with regulatory requirements, is actually cheaper and reduces costs, as compared to not putting any countermeasures in place.

Get support from the various business units in the organization

A good budget proposal should have support of the other business units in the organization. For example, I did suggest to the IT manager mentioned before, that probably he should have discussed with Marketing and explained to them on how a reliable and secure network, would make it easier for them to market with confidence, probably IT would have had no competition for the budget. I don’t believe the marketing people would like to go face customers, when there are possible questions of unreliable service, system breaches and downtime. Therefore you should ensure that you have support of all the other business units, and explain to them how the proposed solution could make life easier for them.

Create a rapport with Management / Board, for even future budget approvals, you will need to publish and give reports to management on the number of network anomalies the intrusion-detection system you recently procured for example, found in a week, the current patch cycle time and how much time the system has been up with no interruptions. Reduced downtime will mean you have done your job. This approach will show management that there is for example an indirect reduction of insurance cost based on value of policies needed to protect business continuity and information assets.

Getting your information security project budget approval, should not be so much of a challenge, if one was to cater for the main issue of value addition. The main question you need to ask yourself is how does your proposed solution improve the bottom line? What the Management / Board require is an assurance that the solution you propose will produce real long term business value and that is aligned with the overall objectives of the organization.

References:

1. Thomson Reuters Accelus, BUILDING A BUSINESS CASE FOR GOVERNANCE, RISK AND COMPLIANCE, 2010.

2. Ponemon Institute, The true cost of compliance, 2011.