|Glossary Quick Links|
|Glossary Master Index|
|Discipline Quick Links|
|Disciplines Master Index|
If you're attempting to learn about or understand different areas of Information Technology or even Information Technology as a whole, whether you're a novice or an expert, this is the place to start. The IF4IT constantly develops and evolves content that falls into various areas of Information Technology. If you're a beginner, use this IT Learning Framework to understand how things fit together in IT Operations and in what order the Foundation believes it makes sense to learn about such topics. If you're more experienced with IT, you may find it more useful to simply jump directly to an area of interest, via links in the Table of Contents, and go from there.
NOTE: The content within this document will continue to evolve, over time. Therefore, the IF4IT recommends you check back regularly, to keep up with changes.
One of the biggest problems in the Information Technology (IT) industry is that most people who get promoted into IT management have no real educational foundation that taught them what things mean (i.e. a common language with standard definitions) and how all things in IT fit together and operate. If you think about it, most people in IT were educated to be "technical" with backgrounds in very specific sub-areas of IT, such as programming with specific programming languages or engineering for things like physical infrastructure. Most technical and business schools do not focus on how IT as an industry, organization or set of technologies all fits together and operates, which is a critical gap for most IT people. Realistically, most IT managers start technical, gain more responsibilities over time, and move away from their technical foundations and more toward the logistical operations and management of IT as an organization, as their careers mature. Interestingly, you would think that after all these decades of IT evolution that there would be a source of knowledge for learning about and understanding what IT means and how it all fits together and operates. The IF4IT found this to be a major industry gap and decided to step in to fill it. One of the results is this learning framework, which exists to help IT stakeholders, whether they're new to the industry or highly experienced, learn about different areas of IT Operations (i.e. how IT operates and why).
Before we go any further, the IF4IT would like to highlight what we believe to be a very important point. The IF4IT chooses to explicitly avoid terms like "Development" (as in Software Development) and "Manufacturing". We believe our reasons for doing so are simple and rational. We believe these terms are too vague and ambiguous and we, therefore, feel they cause confusion when addressing different audiences and stakeholders.
For example, in a small organization, Software Development means doing anything and everything associated with thinking of, planning for, designing, building, packaging, distributing, installing, instantiating, executing, testing and supporting software. Anyone who's ever worked in small, complex software company can tell you that the above example is true. However, when you get into a larger company, segregation of duties or responsibilities will occur, for many reasons, such as economies of scale and perceived security improvements. As a result, distinct organizations will be created to handle isolated activities, such as Project Management Organizations, Architecture & Design Organizations, Coding Organizations, Testing Organizations and Support Organizations. Anyone who's ever worked in large enterprise can tell you this is true, too. Therefore, what does "Software Development" really mean to people in a larger enterprise?
As you can see from the two examples above, the term "Development" represents a much larger concept than just "coding" and building applications as part of a smaller business application development team. It's the same when you think of what "Manufacturing" means to a small company, as opposed to what it means for a large company. It is for these reasons, therefore, that the IF4IT chooses to avoid such vague terms like "Development" and "Manufacturing". While we acknowledge that they exist and we understand we need to deal with them and address them to some level, we also feel they're highly ambiguous and, as a result, cause confusion and act as barricades to learning, when addressing different audiences, such as in the case as Small Company Resources vs. Large Company Resources.
The four contexts are, therefore:
Some commonly used synonyms for "Information Technology" include but are not limited to:
All IT organizations, regardless of the vertical market their enterprise serves, perform three common functions for their customers. These three functions can be summarized as:
|Figure: The Canonical Model for Information Technology (IT)|
Depending on the enterprise you work for or with, these functions might be represented using different synonyms, such as "Plan, Build, Run" or "Strategize, Deliver, Support." There are many permutations of synonyms to represent these functions, however, we always find that there are rarely, if ever, more than three. These functions can also be represented using different pictures, such as a tiered triangle, with Think at the top, Deliver at the center and Operate at the bottom. The Foundation tends to use the three chevron model because it aligns cleanly with other key IT frameworks, such as the Systems Deliver Life Cycle (SDLC), which will be discussed later.
|Thinking represents all activities associated with problem solving, at any level of the enterprise, and includes functions such as Strategy Setting, Research, Planning, Requirements Analysis and Design.|
|Delivering represents all activities associated with the actual procurement, construction, deployment and verification of solutions, post Thinking and pre-Operating.|
|Operating represents all activities associated with the execution, maintenance and support of all solutions that are in the process of being delivered or have been delivered. NOTE: A common mistake that many IT leaders make is to focus only on "Operations" as a form of Production Operations or Production Support, and not giving enough attention to the Operations of other pre-Production environments.|
Because these three functions represent a common and repeatable pattern across all IT organizations, we refer to the set of these functions as "The Canonical Model for Information Technology" (or "The Canonical Model for IT") and will refer to the model, often, throughout much of the Foundation's published content. If you're a novice, the Foundation suggests familiarizing yourself with this model. If you're a more experienced IT professional, you'll probably only have to focus on memorizing the three phase names, if they're different than what you're already familiar with.
IT Operations represents a summary of all three functions in the Canonical Model for IT and represents all things we do to run an IT Organization, both, for ourselves and for our clients.
Any and all functions performed by IT leadership or IT staff, regardless of its scope, purpose or complexity, all falls into the bucket of IT Operations. This tutorial will attempt to break out and document as many IT Operations functions, as possible, as it progresses.
The International Foundation for Information Technology (IF4IT) exists to help people learn about and understand all aspects of IT Operations.
One of the largest and most disturbing problems with the global IT industry is that most IT leaders and staff invent (and re-invent) their own terminology and definitions for describing all the different things they, both, for themselves and for their clients. The truth is that as of the year 2010, you can take ten different IT leaders from ten different enterprises and put them in a room, asking them to define common IT terms and concepts. Sadly, the probability is that all ten will give you different answers.
Clearly, common language becomes the primary obstacle to standardization, throughout the entire industry. Therefore, the IF4IT believes that to start learning about and understanding Information Technology you must start with the language, itself. It's for this reason that we point you to the IF4IT Glossary of IT Terms and Phrases. And, if you're starting with terms, the IF4IT believes there is no better or more important term to start with than the very definition of Information Technology.
The IF4IT Glossary is, definitively, the largest, most comprehensive and most consistent glossary in the world, dwarfing all other IT Glossaries, combined. It is constantly maintained and it evolves to grow and improve, over time. We recommend you use it and check back for updates, regularly.
Given that, both, terminology and language are critical, the IF4IT acknowledges that it's difficult to sit down to read, memorize, and understand all terminology in a glossary that consists of hundreds of thousands of terms. Therefore, we try to make learning such terminology easier by grouping it by the relevant areas of IT Operations that they're associated with. This helps put the terminology in context, making it easier to learn and understand. The "groupings" that we use, at the highest level, revolve around concepts known as "discipline areas" or "enterprise capabilities." As a result, the Foundation has created the IF4IT Master Inventory of IT Disciplines in order to help document, quantify, clarify and categorize the many things that IT Organizations and Staff do (i.e. IT Operations). And, while a linear inventory can be very useful in many situations, the IF4IT Enterprise Capability Model helps order and group many of these disciplines or capabilities, even further.
By acknowledging and understanding this inventory of disciplines, we can see that IT performs many functions for, both, itself and for its non-IT stakeholders, such as Internal Business Counterparts, Partners, Vendors, External Customers, etc. If you feel the list is overwhelming, remember that if IT was easy, there would be no need for IT professionals, like you.
The Foundation acknowledges that the inventory of disciplines is very large and can be difficult to digest, due to its size. It becomes difficult for a novice to understand where to start. However, experienced IT resources understand and acknowledge that to ignore this large list of disciplines is to ultimately diminish an IT Organization's value to the very business that funds it. So, if the list of disciplines is too large to work with, in its raw form, it becomes obvious that we need a better mechanism or set of frameworks that will help make it easier to categorize, compartmentalize and understand all of it. The first of these frameworks, and the most important in the eyes of the Foundation, is the Systems Delivery Life Cycle (SDLC) Framework...
Given a language (i.e. Terms) and an inventory of the many things we do (i.e. IT Disciplines), and an IT Life Cycle that breaks things up into time associated, high-level functions, we can now merge all of these concepts together to simplify the learning and understanding process. We do this by using what the industry calls a "Systems Development Life Cycle (SDLC)."
Synonyms for "Systems Development Life Cycle" include but are not limited to:
Note: Often, the words "Life Cycle" are combined into the compound word "Lifecycle." The Foundation recognizes and acknowledges both to be correct.
The SDLC is one of the most critical aspects of any IT organization as it represents the backbone for the delivery of all IT Assets, whether they be Software or Systems (i.e. a combination of Hardware and Software).
The phases of an SDLC usually look similar to the following:
|Figure: The Systems Development Life Cycle (SDLC)|
It should be obvious and no surprise to anyone that the IT SDLC phases match those of globally accepted best practices for the manufacturing of any product that is delivered to market. The case can easily be made that the phases used in the manufacturing of software, for example, are really no different than those phases used to deliver a car, a house, an airplane, or even a mobile device.
|Phase I - Strategy: This phase represents the work that is performed to ensure that the System Release is fully aligned to all master strategy and intent. It also represents a time period for which System Strategy Owners will work with appropriate stakeholders to develop a high-level strategy or roadmap of work that outlines the details of a specific System Release, with the intent that all work will move forward, throughout the SDLC.|
|Phase II - Research: This phase represents a time period where work is performed to detail opportunities and solutions options that will be presented and ratified, with the intent to decide the value of moving forward and, if the decision to move forward is agreed upon, a direction for how such solutions options will move forward. The goal is to get to a high-level Solutions Architecture and a Solutions Plan that everyone agrees to, before expensive and time-consuming work is started.|
|Phase III - Planning This phase represents a time period for Release Planning, which includes activities such as detailing what will actually go into the Systems Release (i.e. new features, break-fixes, etc.), creating initial project plans (this includes plans that are complete with accountable working organizations and people, as well as with high-level timeframes for the work. Since the SDLC pipeline of phases is a repeatable pattern, most mature enterprises will have project templates that can be used to facilitate the functions within these phases), and improving budget estimates (e.g. +/-25% estimates).|
|Phase IV - Requirements: This phase represents a time period of work that revolves around detailed requirements gathering and analysis for the purpose of clearly specifying what needs to be accounted for in downstream design and implementation activities. The more detailed the requirements, the higher the probability that design will align to intended Systems Release Strategy and with end user expectations for the Release.|
|Phase V - Design: This phase represents a time period for where detailed design is performed, according to Release Plans and Release Requirements. In addition to designing the operational solutions associated with functional and non-functional requirements, the Design Phase also includes designing Unit, Module, Integration, Performance User Acceptance, and Production Signoff Tests that will be used to verify the quality of all work performed in all downstream phases and environments.|
|Phase VI - Procurement & Coding (Code or Coding): This phase represents a period of time during which the detailed design of a System Release is realized and optimized, with the intent that it will be handed off for a centralized and repeatable build that can be used for distribution/deployment, quality assurance and signoff in downstream phases and environments.|
|Phase VII - Centralized Build (Build): This phase represents a time period during which a delegated person or group of people (often referred to as the "Build Master(s)") will focus on creating a fully centralized, repeatable and automated build (automated to the best of his/her/their ability) that will be used for distribution/deployment, quality assurance and sign-off in downstream phases and environments. NOTE: It is during this phase that procurement occurs for any vendor specific products and services that are needed to realize the detailed design.|
|Phase VIII - Integration Testing (Integ): This phase, which is also referred to as "Systems Integration Testing" or "SIT," represents a time period during where all data and technology connections are tested for a specific System moving through the SDLC and all of its upstream System dependencies (i.e. Systems that provide data to the System being tested) and all of its downstream System targets (i.e. all downstream Systems that the System being tested provides data to). The goal is to verify all appropriate data connections and data exchanges between Systems that will need to interact in the final Production operating environment.|
|Phase IX - User Acceptance Testing (UAT): This phase exists to allow for explicit testing of System functions that End Users will be able to execute while operating in the final Production environment. Such testing ensures that what an End User does or sees meets appropriate quality expectations.|
|Phase X - Production (Prod): This phase exists to control all deployment and sign-off of System delivery to the final Production operating environment. No System delivery can be considered to be "complete" until it has been verified and ratified for operation, before final hand-off to the End Users.|
Given this delivery model, we can see that it maintains alignment with the Canonical Model for IT:
|Figure: Alignment of the SDLC (2nd Row) to the Canonical Model for IT (1st Row)|
Note: This section is meant to be nothing more than a short introduction to Operating Environments. Far more information can be found in the Foundation's "IT Environment Framework."
As Systems evolve within and throughout the different phases of the SDLC, they get constructed, verified, and promoted from one working location to another. These locations are what the industry calls "Environments. These Environments are typically virtual locations, in nature, and are not necessarily physical locations, although they can be physically separated as well."
While many environments can exist for various reasons, there are six (6) that are part of the core SDLC. These six environments are:"
|Figure: Standard SDLC Environments|
As can be seen in the following figure, each of these basic Operating Environments directly aligns with its corresponding phase in the SDLC:
|Figure: Alignment of the standard SDLC environments (2nd Row) to their corresponding SDLC Phases (1st Row)|
Alternate Environments: In addition to the standard SDLC aligned environments, listed above, enterprises will create alternate environments to address their own needs or those needs that may be outside of the SDLC, itself. There are many alternate Environments. A few examples include but are not limited to:
What Environments enterprises standardize on are really a matter of the needs of each individual enterprise. However, as most experienced IT Professionals will tell you, the type of enterprises rarely, if ever, need to be that different from one enterprise to another. Most people will voice their belief that they are different. However, when you take the time to dissect their processes and their needs, you'll find that their fundamental needs are really not too different, at all.
Best Practice Note: It is considered a best practice and a sign of maturity when an enterprise does, in fact, standardize its Operating Environments, the process through and around them, the offerings within them, the shared services that enable and support them, and their explicit integration into the enterprise's documented, published, socialized and governed SDLC. A mature experienced IT Professional understands the highly detrimental and negative impacts of manual operations and, therefore, aggressively works to eliminate manual labor or operations within all environments, wherever possible, through the automation of processes that help deliver things to and through Operating Environments. Another sign of maturity comes with understanding the concept of installing "Shared IT Services" that operate within and across appropriate environments. This concept of Shared IT Services will be explored later.
Again, this section is meant to be nothing more than a short introduction to Operating Environments. We recommend that you read and analyze the Foundation's "IT Environment Framework for a greater understanding of Environments, their purposes, how they're provisioned, and how they work."
Once an enterprise has standardized on the environments its Systems will pass through, as they move through the SDLC, it becomes clear that the functions performed on or for any given System, in any environment, follow a repeatable pattern.
As a matter of best practice and as a sign of maturity, enterprises that understand Information Technology (IT) Operations will automate as many of the above functions as possible to eliminate waste and to optimize their costs. We will discuss which areas should be automated and why, further in this document.
Another sign of IT maturity and best practice is to ensure that each of the above functions is accounted for in all project plan templates that are used to control delivery of any System, through the SDLC. Enterprises that deliver solutions through their SDLC, over and over again, use templates to ensure 1) that they don't reinvent the wheel every time they start a new project and 2) to ensure "completeness" of work that needs to be performed, throughout the project. Having all of the above functions listed in your project plan, as clear milestones with clearly defined sub-tasks, in each and every environment, can only help increase the success of delivery for any project.
Every IT Organization deploys its Assets to Operating Environments for the target End Users of such Environments.
Successful enterprises make these IT Deployment Functions highly repeatable, especially through automation, and manage them, rigorously, to ensure high-levels of repeatability, quality and transparency, while simultaneously working to proactively reduce their costs.
The Foundation has documented these functions in it's IT Deployment Framework, which you can use to help you and your enterprise learn about and understand what are considered to be the very foundation for all IT Delivery.
Very simply there are four fundamental project categories or types that drive how IT organizations delivery solutions for themselves and their business counterparts. These four include:
NOTE: Each project "type" can further be broken down into levels of complexity, depending on multiple variables such as size and amount of work associated with them, costs, access to resources, etc.
1. Artifact Only Projects: Artifact Only Projects deliver no hardware or software of any form. The deliverables from such projects are typically "documents." An example of an Artifact Only Project is when a company funds a project to reduce all of its vendor costs. The project team engages vendors, partners, etc. and only delivers things like documentation, which do not need to adhere to formal build, deployment and operations procedures, as would computers and/or software.
2. Infrastructure Only Releases: Infrastructure Only Releases are projects that are intended to build and deploy pieces of physical infrastructure, such as computing servers, networks and/or network components, storage solutions, etc. These types of projects, like Artifact Only projects, are hot subject to the rigor of Software related projects, which have to go through different environmental testing. However, unlike Artifact Only projects, Infrastructure Only Releases are projects that do have "some" rigor that they must follow. For example, infrastructure solutions are often built and tested in isolated environments and then deployed to their target environment for eventual "turn on" and use by appropriate people and systems in those target environments. As part of the build and release of such constructs, Artifacts are also generated and delivered. Examples include but are not limited to: Build Artifacts, Deployment/Distribution Artifacts, Installation Artifacts, Instantiation and Initialization Artifacts, Execution Artifacts, Testing Artifacts, Support Artifacts, etc.
3. Software Only Releases: Software Only Releases are projects that involve the coding, building, deployment, testing and signoff of software, across multiple environments, such as Common Build Environments, Systems Integration Testing Environments, User Acceptance Testing Environments, Production Environments, etc. In the case of a Software Only Release, the infrastructure that the software will leverage (whether it be for build, deployment, test, execution, etc.) is already in place and only the software constructs, themselves, move across environments. This is very common among software vendors who build and sell software as part of their businesses. Unlike Artifact Only and Infrastructure Only projects and releases, Software Only Releases go through more environments for the purpose of more rigorous software functional testing. Like Artifact Only and Infrastructure Only projects and releases, Software Only Releases will deliver many documents, in addition to software. Refer to Infrastructure Only Releases, above, for examples of such artifacts.
4. Software System Releases: Software System Releases are, more often than not, the most complex form of all IT projects. They encompass all of the other project types (Artifacts, Infrastructure and Software), including but not limited to things like data integrations to/from other systems and/or file movement and transformation across and throughout the enterprise.
In short, a Project is a coordination of work to achieve a specific set of outcomes. A "Release" is, in short, a certain type of Project that represents all the work associated with the inception, planning, design, development, testing and deployment of a versioned Product, to its target audience. In other words, a Release is nothing more than a "Product Version" and all its associated artifacts and constructs, bundled together, coordinated, controlled and executed in the form of a master Project that can be composed of many smaller Projects and which exists to specifically deliver technical infrastructure and/or software. Unlike many business-only Projects, with a Release there is an expectation that the delivered infrastructure and/or software must be constructed, deployed, tested and operated, across multiple "environments" before being delivered to its target audience, where the environments and the functions performed within them tie to the IT Systems Development Life Cycle (IT SDLC).
A "Product" represents anything that is created, constructed, delivered and managed to a targeted audience.
A "Product Release" represents a specific version of a "Product," including the bundled features that define and constrain functionality, the work that was performed (or is to be performed), and all of the associated artifacts and constructs that were generated (or will be generated), from inception of the Release, through to its delivery.
"Software" represents the non-executed or non-executing electronic constructs that, when build, distributed, installed, instantiated, initialized and executed, help automate one or more processes that would otherwise have to be executed manually (i.e. by one or more humans).
An "Application" represents a running or executing set of "instances" of one or more pieces of software.
A "System" represents a group or collection of parts, components or entities, even human or pertaining to a human, that are interdependent upon one another and work or act together to achieve a common set of Outcomes. Therefore, a Software System is often representative of one or more Applications and all of their associated constructs, be they computing devices, non-computing devices, artifacts, etc.