Glossary

A

activity A collection of tasks within a particular process; where the work is done.

analyzing risk Converting risk data into risk decision-making information.

antipatterns See design patterns and antipatterns.

application A grouping of software for the purpose of solving a business problem.

application architecture The design and plan for building an application, as well as certain consistent styles of application construction.

Application Model One of the six core models of MSF. The MSF Application Model for Development (MSF Application Model) provides a three-tier services-based approach to designing and developing software applications. MSF views an application at a logical level as a network of cooperative, distributed, and reusable services that support a business solution. The model describes applications as using three services: user, business, and data.

Application Perspective Part of the Enterprise Application Model. The enterprise architecture from the point of view of the applications used to support business processes.

architecture A design and plan for building something; also, the style of that plan or design. See also enterprise architecture, application architecture.

architecture first An approach to IT planning and implementation that emphasizes basing such work on a well-thought-out, well-understood enterprise architecture. It represents a commitment that all three parts of the IT task—planning, building, and managing—are based on a coherent, higher-level architecture; that the architecture has been worked out before the start of the coding work; and that the architecture drives the work.

artifact Documents of all kinds that are generated as part of the project. See also deliverable.

B

best practice Refers to recommended procedures to follow. The term does not imply that best practices that will always produce successful results.

buffer Time added to a project schedule to help the project team accommodate unexpected problems and changes. It is typically created by setting an internal deadline that occurs sooner than the external one that has been publicized.

bug Any issue arising from the use of the product.

build strategy One of the four strategies designed to extricate an organization from the IT abyss. The build strategy endeavors to define a long-term infrastructure target that increases flexibility while maintaining cost levels.

business function Business functions are the highest level of what business processes are intended to accomplish. For example, financial management is a business function; accounts receivable is a related business process. See also business process, business process decomposition.

Business Perspective One of the four perspectives in the Enterprise Architecture Model. The business perspective views the enterprise architecture from the point of view of the business processes. It includes broad business strategies and plans for moving the organization from its current state to its desired future state. The business perspective describes how the business works. Subtopics might include the organization's high-level goals and objectives, the organization's products and services, business processes that embody the functions and the cross-functional activities performed by the organization, major organizational structures, and the interaction of all these elements.

business process A process is "a structured, measured set of activities designed to produce a specified output for a particular customer or market. It implies a strong emphasis on how work is done within an organization." (Davenport, Harvard Business Review, 1993). Business processes have customers and in most cases (but not always) cross-organizational boundaries.

business process decomposition A top-down hierarchical way of analyzing in detail an organization's business processes. The flow of analysis usually proceeds in the following order: function, process, activity, and task. Business rules and processes usually apply at the task level. See also business process.

C

candidate project list During the planning phase of the enterprise architecture, determining which IT projects to undertake requires complex tradeoffs in uncertain situations. The candidate project list helps IT planners to balance business needs and goals against technological possibilities and risks and prioritize projects for a versioned release of the enterprise architecture.

client/server architecture See two-tier architecture.

Conceptual Design The process of acquiring, documenting, validating, and optimizing business and user perspectives of the problem and the solution. Its purpose is to capture and understand business needs and user requirements in their proper context. The output of Conceptual Design is a set of information models, use cases, and usage scenarios that document the current and future states of the system. See also Logical Design, Physical Design, Design Process Model.

control strategy One of the four strategies designed to extricate an organization from the IT abyss. Organizations in the IT abyss attempt to get all IT under control by setting funding targets for future application and infrastructure spending.

controlling risk Addressing the results of risk tracking and the process as a whole.

critical success factors The activities, tasks, technology, funding, and milestone requirements that must be accomplished before an organization can reach its long-term goals and objectives. Similar to dependencies.

current state assessment An assessment of the actual present-day status of the organization's business processes, applications, information stores, and technological support made during the planning phase of the enterprise architecture.

customer-focused mindset A best practice or principle of a successful team, it means committing to understanding and solving the business problem, focusing on the alignment of business and technology, and involving the customer throughout the process.

D

deliverable A physical artifact created by the team, usually associated with reaching an interim or major milestone. It can be the only product or one of several products associated with that milestone.

design patterns and antipatterns A design pattern is instructive information that captures the essential structure and insight of a successful family of proven solutions to a recurring problem that arises within a certain context and system of forces. It identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. Design patterns can be either generative or non-generative. Generative patterns can be used to solve engineering problems, whereas non-generative patterns are merely observed. Generative design patterns provide complete solutions to business and technical problems. They are primarily geared toward "green field" designs, meaning they are applied to new designs.

A design antipattern is geared toward solving problems for which an inadequate solution is already in place. The best way to differentiate patterns and antipatterns is to say that patterns lead to an original solution for a set of criteria and forces, while antipatterns lead to a new solution when the current design is not working. Thus patterns are used when starting from scratch, and antipatterns are used to fix things that are broken.

Design Process Model One of the six core models of MSF. The MSF Design Process Model is based on three different phases—Conceptual, Logical, and Physical Design—that provide three different perspectives for three different audiences—users, the project team, and developers.

desired architecture The future envisioned state of the enterprise architecture.

Developing Phase The third of four distinct phases of the MSF Development Process Model, it is the period during which all projects for the versioned release are initiated. It culminates in the Scope Complete Milestone, indicating all projects have been started and preparations have been made for external testing and stabilization.

Development Process Model One of the six core models of MSF. The MSF Process Model for Application Development (MSF Development Process Model) is a project life-cycle model that is milestone-based, iterative, and flexible. It describes the phases, milestones, activities and deliverables of an application development project and their relationship to the roles of the MSF Development Team Model. It includes four phases (Envisioning, Planning, Developing, and Stabilizing), each with its own major milestone (Vision Approved, Project Plan Approved, Scope Complete, and Release). See also each of the phases and deliverables.

Development role One of six MSF team roles. It acts as technology consultant to the team and is responsible for actually writing the application.

Development Team Model One of the six core models of MSF. The MSF Team Model for Application Development (MSF Development Team Model) provides a flexible structure for organizing project teams. It emphasizes both clear roles and responsibilities and clear goals for team success, and it increases team member accountability through its team of peers approach. It consists of six roles: Product Management, Program Management, Development, User Education, Testing, and Logistics Management. See also each of the six roles, respectively.

digital nervous system Analogous to a biological nervous system in that it provides an organization with the information it needs. It supports basic business operations, prepares an organization to react to both planned and unplanned events, and helps to gain and/or maintain a competitive advantage.

E

Enterprise Application Model An architecture model for designing and building enterprise applications. The model consists of six submodels: Business, User, Logical, Technology, Physical, and Development.

enterprise architecture A structure that describes the organization's business activities, the applications and automation that support those business activities, the information necessary to carry out those business activities, and the technologies and infrastructure used to deliver the applications and information. It results in a logically consistent plan of activities and coordinated projects that guide the progression of an organization's application systems and infrastructure. The plan should move from the current state to a desired future state based on current and projected business objectives and processes.

Enterprise Architecture Model One of the six core models of MSF. The MSF Enterprise Architecture Model provides a consistent set of guidelines for rapidly building enterprise architecture through versioned releases. The model aligns information technology with business requirements through four perspectives: Business, Application, Information, and Technology.

enterprise architecture planning The process of working from a current state to an envisioned future state of the enterprise architecture. The process anticipates and plans for the obstacles that impede progress toward initiation of projects that will move the organization forward.

enterprise architecture process A rational way to make decisions that lead to action rather than reporting. Once this rational process is in place, you can focus on project selection and prioriti-zation and "plan while building" rather than plan first and then build.

Envisioning Phase The first phase of the MSF Development Process Model, during which the project team is assembled and comes to agreement with the customer on the project vision and scope. The Envisioning Phase culminates in the Vision Approved Milestone.

execute strategy One of the four strategies designed to extricate an organization from the IT abyss. Organizations eager to leave the IT abyss focus on execution, in both operations and new development to reach competitive status as soon as possible.

extend strategy One of the four strategies designed to extricate an organization from the IT abyss. A strategy for organizations that aspire to lead and must focus their energies on identifying and testing new opportunities while continuing to drive performance.

F

feature team In large projects, a multidisciplin-ary subteam that is responsible for a particular feature set.

features One of the three sides of the tradeoff triangle, the other two being resources and schedule, it refers to the product and its quality.

four perspectives Together, they make up the Enterprise Architecture Model. MSF uses the acronym BAIT to refer to the four perspectives: Business, Application, Information, and Technology.

function team In large projects, a subteam within a role. They arise when a team or project is large enough that it requires the people within a role to be grouped into teams based on their functionality.

Functional Specification A deliverable that describes the solution in explicit detail.

G

gap analysis A study that is conducted to discover the gap between the current state and the desired state of the enterprise architecture.

goal What the business intends to accomplish or attain.

guideline A recommended course of action to achieve particular ends.

I

identifying risk Discovering and recognizing potential problems with the project.

information What the organization needs to know to run its business processes and operations. It includes standard data models, data management policies, and descriptions of the patterns of information consumption and production in the organization.

Information Perspective Part of the Enterprise Application Model. The enterprise architecture from the point of view of the information that the organization has stored for its use.

information store A database or other kind of repository where information in all of its forms is kept.

information technology (IT) The architecture, structures, and processes that are the core of an information systems strategy.

initial candidate project list See candidate project list.

interim milestone A point in time that signals a transition within a phase and helps to divide large projects into workable pieces. See also milestone, major milestone.

IT abyss A model that describes the gap between an enterprise and its ability to maximize value from its IT investments. The IT abyss is the most prominent feature of the IT landscape and represents the present state of an organization on the IT landscape chart, situated between past and future states. An organization's position relative to the abyss on the IT landscape chart determines which of four strategies it should adopt to help it get out of or across the IT abyss.

IT assets What the organization has, grouped in three main areas: application portfolio, technology infrastructure, and IT organization.

IT/business performance The organization's current performance, grouped in two main areas: spending and results.

IT diagnostic areas Enterprise architecture planners can evaluate an organization's current IT environment in three key diagnostic areas: IT assets (what the organization has), IT management processes (how things are done), and IT/business performance (current performance).

IT inventory A quick, high-level inventory across the enterprise, looking only at the details of the areas that the vision identifies as being of interest. The IT inventory of an organization can be divided into three categories:

• Applications Systems made up of executable software.
• Information Computerized data stores containing information, often accessed through a database management system.
• Technology Hardware, software, and electronic networks that support applications and data stores.

For analysis purposes, an organization's IT inventory also includes items that are planned or under development.

IT landscape A graphical representation of an organization's IT assets evaluation depicting past, present, and future performance. The IT abyss model describes varying levels of the IT landscape. Factors contributing to the IT abyss include IT assets, IT management processes, and IT business performance.

IT lifecycle The process of planning, building, and managing information technology.

IT management processes How the organization does things, grouped in five main areas: strategic direction-setting, technical direction-setting, funding, execution, and review.

L

Logical Design The process of describing a solution in terms of the organization, structure, syntax, and interaction of its parts from the perspective of the project team. The purpose of Logical Design is to apply the services-based organizing principles of the MSF Application Model, and to lay out the structure of the solution and the relationship among its parts. The output of Logical Design is a set of business objects with corresponding services, attributes, and relationships; a high-level user interface design; and a logical database design. See also Conceptual Design, Physical Design, Design Process Model.

Logistics Management role One of six MSF team roles. It is responsible for acting as advocate for the operations, product support, Help Desk, and other channel organizations.

M

major milestone Achieving a major milestone represents team and customer agreement to proceed and signals a transition from one phase into the next. See also milestone, interim milestone.

Microsoft Solutions Framework (MSF) A framework developed by Microsoft for planning, building, and managing distributed computing systems. MSF is a set of proven practices for organizing software development teams and project planning that can be applied to planning and implementing almost any form of computing technology.

milestone A point at which the team assesses progress and makes mid-course corrections. Milestones are review and synchronization points, not freeze points.

mitigating risk The practice of predicting and then taking steps to eliminate risk from a proposed course of action.

MSF See Microsoft Solutions Framework.

multi-layer architecture See N-tier architecture.

N

N-tier architecture An application architecture in which the presentation, business, and data tiers are logically separated. Also called three-tier architecture. "N-tier" is becoming the preferred term since it implies (correctly) that the logical separation of services can result in more than three tiers. See also two-tier architecture.

O

objective Represents what an organization wants to achieve in the long-term. See also goal.

P

patterns See design patterns and antipatterns.

phase One of four distinct divisions of the MSF Development Process Model, culminating in a major or external milestone.

Physical Design The process of describing the components, services, and technologies of the solution from the perspective of Development. Its purpose is to apply real-world technology constraints to Logical Design, including implementation and performance considerations. The output of Physical Design is a set of components, a user interface design for a particular platform, and a physical database design. See also Conceptual Design, Logical Design, Design Process Model.

plan, build, manage IT lifecycle The fundamental life cycle upon which MSF is based. Enterprise architecture focuses on the planning aspects of the MSF lifecycle.

Planning Phase The second phase of the MSF Development Process Model that culminates with the Project Plan Approved Milestone.

postmortem A formal process of reviewing what went right and what went wrong with a project as a way of learning for the future.

proactive analysis An evaluation of how new and unused technologies can be applied to the organization. In this approach, planners do not treat the boundaries of current business practices as limitations, but try to change business processes through a new application of technology in a way that adds value to the organization. The proactive approach means that IT professionals have to imagine future directions that the organization might take and look for ways to apply new or unexploited old technologies to business. See also reactive analysis.

process A collection of activities that yield a result, product, or service; usually a continuous operation.

process decomposition See business process decomposition.

Process Model See Development Process Model.

Product Management role One of six team roles in MSF. It acts as the customer advocate to the team and the team advocate to the customer.

product mindset A best practice or principle of a successful team, it means the team treats the work performed as a product, enabling it to use a versioned release strategy to prioritize features and address changes.

Program Management role One of six MSF team roles. It is responsible for driving the timely development of the solution. The program manager drives critical tradeoff decisions, facilitates team communication, and manages the schedule and resource allocation, but is not the "boss" as he or she might be in a traditional top-down project team.

Project Plan Approved Milestone The major milestone at the end of the Planning Phase that represents the point at which the project team, the customer, and key project stakeholders agree on the project deliverables. This milestone provides an opportunity to establish priorities and set expectations, and serves essentially as a contract between the project team and the customer.

R

reactive analysis A top-down approach in which the organization initiates no action unless an event of some kind threatens the status quo. Then an individual or a team is given the task of forestalling change or attempting to control change as the organization drifts toward another—usually unplanned-for—state.

Release Milestone The major milestone at the end of the Stabilizing Phase that represents the point at which the team has addressed all outstanding issues and ships the product, placing it in service. At the Release Milestone, responsibility for ongoing management and support of the product officially transfers from the project team to the operations and support groups.

resources One of three sides of the tradeoff triangle, the others being schedule and features, it includes people and money.

retiring risk Eliminating risk from the risk plan. One approach to retiring a risk is to archive the risk and its management plan (successful or otherwise) into a repository for use and reference by future projects. Conversely, risks can be simply removed from the risk management process after they have occurred or been resolved.

risk The possibility of loss or injury; a problem waiting to happen.

risk assessment Determining risk probability (the likelihood risk will occur) and risk impact (the severity of loss if the risk does occur).

Risk Assessment Document A consolidation of the team's risk management output in a single document.

risk contingency Addressing what to do if a risk occurs.

risk contingency trigger The criterion for executing a contingency plan.

risk exposure A quantification of the overall threat constituted by a risk, it is calculated by multiplying probability times impact.

risk impact The severity or magnitude of loss if a risk occurs.

risk management A proactive process of identifying, analyzing, and addressing risk.

Risk Management Model One of the six core models of MSF. The MSF Risk Management Model provides a structured and proactive way to manage project risks. It consists of five steps: identify, analyze, plan, track, and control.

risk planning Anticipating risks with consequences that an organization cannot accept. Risk planning involves examining how much is known about the risk, and if the organization can live with the consequences, or avoid the risk entirely. The plan can include a way to reduce the likelihood the risk will occur, and determine ways to reduce the impact should the risk occur.

risk probability The likelihood that a risk will occur.

risk source Where a risk can originate.

risk statement A condition-consequence statement that helps to clearly articulate risk.

S

scale A way of adjusting the scope of a planned project so that it matches a fixed ratio or actual need.

scale down To narrow the scope of a project or plan.

scale up To expand the scope of a project or plan.

scenario A single sequence of interactions between objects and actors. A scenario illustrates a particular instance of a use case and can show either the current state of the process or a desired future state. See also use case.

schedule One of three sides of the tradeoff triangle, the others being resources and features, it means time.

Scope Complete Milestone The major milestone at the end of the Developing Phase that represents the point when all features are complete and the product is ready for external testing and stabilization.

shared project vision A best practice or principle of a successful team, it means clearly understanding project goals and objectives, and understanding and buying into a vision that is held by all team members and the customer. It is important because it provides the team with a uniform sense of purpose, resolves conflicting and con-tradictory visions, clarifies project goals and objectives, and ensures that team members are working toward the same goal.

Spiral Model A project lifecycle model that is primarily iterative. The stages of application development that make up this model are typically characterized as inception, elaboration, construction, and transition. Within each stage are five activity phases: requirements, design, implementation, deployment, and management. The Spiral Model's process is a continual circle through the stages of development, with each stage requiring multiple revolutions through the five phases.

Stabilizing Phase The last of four distinct phases of the MSF Development Process Model, it is the period during which all team efforts are directed at addressing all issues derived from feedback. No new development occurs during this phase. It culminates in the Release Milestone, at which point responsibility for the product shifts to the operations team.

standard Established or prescribed course of action or procedure to be followed for specific situations, operations or business processes.

strengths, weaknesses, opportunities, threats Factors in an organization that may impact proposed solutions to enterprise architecture problems. Analyzing these factors may influence IT decisions. See also SWOT analysis.

SWOT analysis A way to evaluate strategies with respect to the organization's resources and environment.

T

Team Model See Development Team Model.

team of peers A fundamental concept, underlying the team model, which says each role on a project team brings a unique, valuable perspective to the team that must be equally valued.

Technology Perspective Part of the Enterprise Application Model. The enterprise architecture from the point of view of the technological infrastructure that supports the business processes.

Testing role One of six MSF team roles. It is responsible for making sure that all issues are known to the team and addressed prior to releasing or deploying.

three-tier architecture See N-tier architecture.

top ten risk list An identification of the ten top priority risks, taken from the risk assessment document.

tracking risk Monitoring the risks and their mitigation plans.

tradeoff triangle A triangle of project variables whose three sides are resources (people and money), schedule (time), and features (the product and its quality). It is used to make project tradeoffs. A change to one side requires that the team make a correction on one of the sides to maintain project balance, including potentially the same side on which the change first occurred.

two-tier architecture Also known as client/server architecture. In a two-tier architecture, a client process handles the data processing and presentation parts of the application. Data is stored on centrally administered server machines. Clients connect directly to the servers they need, often for the lifetime of the application's use. See also N-tier architecture.

U

undesired architecture The enterprise architecture that results when an organization does not attempt to plan for the future.

Unified Modeling Language (UML) A language used to model software systems. Its primary purpose is to help organizations visualize, specify, create, and document the artifacts of a software system. It evolved from several primary modeling languages that were prevalent in the late 1980s and 1990s. It consists of modeling elements, relationships, extensibility mechanisms, and diagrams.

Unified Process Model (UP) A life-cycle model used for the analysis, design, and implementation of enterprise applications. It requires extensive use of the Unified Modeling Language (UML) modeling, and is use-case driven, architecture-centric, iterative, incremental, risk-confronting, object-oriented, and layered. It is a repository for object-oriented system development patterns, objects, and code. See also workflow.

use case A behaviorally related sequence of interactions performed by an actor in a dialogue with a system to provide some measurable value to the actor. See also scenario.

User Education role One of six MSF team roles. It is responsible for acting as the advocate for the user of the product.

V

versioned release Providing the most critical functionality for a product in the first version and postponing other desirable features into later releases.

Vision Approved Milestone The major milestone at the end of the Envisioning Phase that represents the point at which the project team and the customer agree on the overall direction for the project, including what features and functionality the product will and will not include.

Vision Document A major milestone at the end of the Envisioning Phase that sets forth all the projects and goals for the next versioned release of the product.

Vision Statement A deliverable that expresses the long-term vision of the product and provides a context for decision-making.

W

Waterfall Model A project lifecycle model that is primarily linear. It is an orderly, highly structured process based on the following well-defined development steps: system requirements, software requirements, analysis, program design, coding, system test, and operations.

willingness to learn A best practice or principle of a successful team, it means committing to self-improvement through gathering and sharing knowledge and institutionalizing learning using such techniques as reviews and postmortems. It is important because it allows team members to benefit from mistakes, helps them repeat successes, and mandates time for the team to learn.

workflow Five core processes within the Unified Process model that are continually executed during the four phases of the development process until the application is completed. Each completion of the five workflow steps is called an iteration, and each iteration culminates in an internal product release. The workflows are requirements, analysis, design, implementation, and testing. See also Unified Process Model (UP).

Z

zero-defect mindset A best practice or principle of a successful team, it means committing to quality, performing work at the highest possible level of quality, and focusing on achieving the quality bar set by the team. It is important because it increases product stability, schedule predictability, and accountability.