Module 1: The Total Solution Life Cycle
Lessons Covered in This Course
Lesson 1: Introducing the Players and Their Roles
Lesson 2: Developing Business Strategy and Plans
Lesson 3: Building a Solution: Overview of Frameworks and Methodologies
Lesson 4: Deploying and Operating a Solution
This module takes you through the total solution life cycle. The total solution life cycle includes the business strategy and business planning activities that precede the software development life cycle (SDLC), as well as the deployment and ongoing operations that follow. We examine the tools used to create business strategies, develop and implement solutions, and evaluate solution effectiveness. A solutions architect that understands the total solution life cycle can make better decisions than a peer who understands only the SDLC.
· Microsoft® Certified Architect Program Solutions Architect Competencies
Lesson 1: Introducing Players and Their Roles
· The Players and Their Roles
· Interacting with the Players
Lesson 2: Developing Business Strategies and Plans
· Business Strategy Planning
· Norton & Kaplan Strategy Maps
· Strategy Canvas
· Investment Calculations
Lesson 3: Building a Solution: Overview of Frameworks and Methodologies
· Enterprise Architecture Frameworks
· Development Models
Lesson 4: Deploying and Operating a Solution
· Overview of Deployment and Infrastructure Impact
· Operations and Infrastructure Frameworks
· Solution Valuation
Sample Scenario: Soccer Stadium Season Tickets Resale System
The goal of this curriculum is to help an aspiring solutions architect to focus on the development of the competencies that are required to become an effective solutions architect.
The MCA program has defined seven competencies that are useful in categorizing the skills necessary to become a competent solutions architect. We will be referring to these competencies throughout this curriculum. These seven competencies are the following:
· Organizational dynamics
· Process and tactics
· Technology breadth
· Technology depth
While aspiring solutions architects may find their roots in many professional disciplines, most come from a strong development background. This is why solutions architects often have sufficient competency in the areas of technology breadth and technology depth as well as some experience in process and tactics. Effective architects must also invest the time needed to refine their capabilities in the remaining competency areas, which are sometimes classified as soft skills.
Microsoft Certified Architect Program Solutions Architect Skills
The Microsoft Certified Architect program has defined skills in which a candidate architect must prove their competency.
Candidates demonstrate that they can develop partnerships with stakeholders both inside and outside the organization on their projects, that they can mentor others, that they develop and form strong teams, and that they achieve successful results. The following are some ways to demonstrate these qualities:
· Ask thought-provoking questions that result in actionable technological patterns or solutions.
· Actively mentor others.
· Provide thought leadership by enabling others to see things from a different and better perspective.
· Influence decisions.
· Champion structure, process, best practices, and standards.
· Promote the capture and reuse of intellectual capital.
· Effectively build individual partnerships and organizational networks.
Candidates demonstrate that they maintain well-written and accurate project documentation, and that they are able to present information about a technical subject in a concise and measured manner. Candidates have the ability to influence others, they manage conflict effectively, and they tailor their communication to the needs of the target audience. The following are some ways to demonstrate these qualities:
· Be an effective listener and astute observer.
· Communicate effectively and persuasively to different audiences (for example, executive or technical).
· Effectively mediate and manage conflict.
· Document designs and specifications that adhere to company practices.
· Communicate needs as well as deployment and operations standards to infrastructure architects.
· Effectively facilitate meetings.
· Possess good presentation skills.
Candidates demonstrate that they can recognize the key stakeholders on a project and that they can work with those stakeholders to drive a project to a successful conclusion. Candidates recognize the political landscape in an organization that can influence a project, and they can, in turn, influence organizational politics for the success of their projects. The following are some ways to demonstrate these qualities:
· Understand organizational structures, relationships, and influencers.
· Maneuver through politically-charged organizational situations.
· Effectively build organizational partnerships and networks.
· Build relationships with other architects and project stakeholders.
· Possess an awareness of the internal legal organization and ensure that legal guidelines are met.
· Exhibit comfort with conflict and thrive in situations that require negotiation and compromise.
Candidates apply their knowledge of technology to further organizational goals within their vertical industry. They understand the principles of project management and interact with project managers to successfully complete projects. In addition, candidates understand the economic dimension of projects and how costs influence the available choices for technology. The following are some ways to demonstrate these qualities:
· Explain the business strategy of your organization.
· Demonstrate knowledge of industry-specific trends with respect to architecture.
· Balance the needs of users, management, operations, support, finance, and technology with the strategic needs of the business, including business benefits and vendor pricing implications.
· Demonstrate an understanding of future trends in technology and how they impact the current and future state of your solution.
· Describe how you applied knowledge of industry (HIPAA, Basel II, Sarbanes-Oxley, HL7, and so on) regulations to create your solution.
· Use enterprise frameworks. For example, use the Zachman Framework for Enterprise Architecture or The Open Group Architecture Framework (TOGAF) to map the business strategy of the organization to your solution.
· Understand operational frameworks. For example, understand how Control Objectives for Information and related Technology (COBIT) or IT Infrastructure Library (ITIL), impact your solution.
· Understand techniques for achieving operational excellence. For example, understand how Lean Six Sigma, Total Quality Management (TQM), and Capability Maturity Model (CMM) impact your solution.
Process and Tactics
Candidates demonstrate that they can gather and refine project requirements from both a technical perspective and a business perspective. They design, create, maintain, and verify models of the deployed infrastructure. They also create effective project artifacts. They exhibit the ability to refine project goals and the tactics necessary to achieve those goals as the project develops. The following are some ways to demonstrate these qualities:
· Use methodologies and/or frameworks to provide predictability to IT and ensure repeatable success on IT projects.
· Gather and analyze both technical and business requirements.
· Envision and create a solution that meets requirements and can be implemented using modeling techniques and mapping their points of integration.
· Prove the feasibility of a design (proof-of-concept, pilots, prototypes, and so on).
· Use capacity planning techniques to ensure scalable designs.
· Create the design artifacts that are required to deliver and maintain the solution.
· Understand the impact of internal policies, such as service level agreements (SLAs).
· Guide a project through to completion and audit compliance with specifications and the overall intent of the architecture.
· Review the ongoing implementation for opportunities for improvement and refine the model as requirements change, implementation choices evolve, and so on.
· Contribute to technical project management.
Candidates understand architectural best practices and are able to apply them across a breadth of technologies to orchestrate a solution. Candidates can articulate their views on the future development of a technology, they understand the interaction between infrastructure and solution architecture. They use these insights to design appropriate architectural solutions. The following are some ways to demonstrate these qualities:
· Apply architectural and engineering concepts to design a solution that meets operational requirements, such as scalability, maintainability, security, reliability, extensibility, flexibility, availability, and manageability.
· Think abstractly and demonstrate effective application of service-based, object-based, and component-based modeling.
· Effectively adapt solutions to the capabilities and constraints of the infrastructure.
· Demonstrate a range of software development skills, such as:
· Data access and transactions.
· Factoring and refactoring.
· Tiers and layers.
· Application of patterns.
· Integration strategies.
· Have a broad architectural knowledge of several technology areas and be able to compare and contrast multiple vendor offerings in those areas.
· Learn new concepts and gain expertise quickly.
Candidates demonstrate that they have a detailed knowledge of the concepts and application of at least two competencies. Candidates also demonstrate the ability to quickly assimilate information about new technologies. Examples of competencies include, but are not limited to, the following:
· Component and solution modeling.
· Solutions frameworks such as the Microsoft .NET Framework and Java 2 Platform, or Java 2 Platform, Enterprise Edition (J2EE).
· Integration, as evidenced by knowledge of traditional enterprise application integration (EAI) products such as Microsoft BizTalk Server, IBM WebSphere, or BEA WebLogic.
· User experience, including smart clients and adaptive UI.
· Data structuring and management.
Exercises for Understanding
· Rate yourself in each competency.
· Ask yourself which leadership behavior is most important.
Lesson 1 introduces the players and their roles to provide context around the soft skill competencies of leadership, communication, organizational dynamics, and strategy.
Topic 1: Overview
Examining the total solution life cycle provides solutions architects with insight into the processes and players involved before, during, and after typical solution development. This lesson addresses the individuals, their strategies and plans, and the motivational influencers a successful solutions architect must understand.
As a solutions architect invests the time to understand the roles of the other players in the total solution life cycle, they build the necessary insight and trust that is critical to effective interactions on successful projects.
To Learn More
We use the areas of solutions architect competencies identified by the MCA program in Appendix A as skill goals throughout this lesson.
Topic 2: The Players and Their Roles
First we will examine the individual’s motivations and roles in the total solution life cycle. Figure 1-1 illustrates the roles that impact the solution during the total life cycle through a presentation of the general stages and resources involved over time. It is neither a framework nor a methodology (which can be iterative and are covered in later lessons) and is meant to be read (going from left to right) with the general stages being measured in days, weeks, months, or years.
Because Figure 1-1 reflects the current state of solutions today, it is not optimal. The solutions architect, along with every other role in the solution, must adapt and exist in the imperfect world of solution delivery. This diagram can be used to identify and communicate existing shortfalls (identified below) to make better roles interaction a common goal.
Figure 1-1. The total solution life cycle
Individuals in a solution often perceive their roles as crossing the boundaries shown in the diagram.
A solutions architect recognizes each of the roles and considers how best to work with the other participants throughout the total solution life cycle.
Exercises for Understanding
· Consider a recent project that you were involved in. Draw a diagram that reflects the reality of the roles and timelines for your project. How does it differ from Figure 1-1?
Topic 3: Interacting with the Players
This topic provides more detail about each of the roles in a solution and how a solutions architect might best interact with those roles.
In medium-to-large for-profit organizations, the primary business stakeholders include executive management: Chief Executive Officer (CEO), Chief Financial Officer (CFO), Chief Operations Officer (COO), Chief Technology Officer (CTO), and Chief Information Officer (CIO). There are others emerging in industry such as the Chief Security Officer (CSO). These “C-level” managers are generally the leadership of a company or organization. These roles may have different titles, or one person may assume multiple roles, but the responsibilities associated with these roles do not greatly vary.
Often, secondary business stakeholders will emerge for a particular solution. A sales and marketing–driven solution might include the director of marketing and a manufacturing solution might include key production management.
Generally, there is a strong financial component around the business strategy. In addition, regulatory mandates drive many business decisions.
It is a business stakeholder’s vision and direction, not technology, that moves a business forward or backward.
The attachment to technology and the understanding of it by business stakeholders also varies. As a technologist, the solutions architect must align the contribution by technology with the business strategy. If the business strategy is not adequately documented or presented, the solutions architect must engage communications and organizational dynamics skills to achieve this alignment.
Consider for Yourself
· Solutions architects understand the importance of early and sufficient engagement of the business stakeholders. Discuss solutions you have been involved in. At what level were the business stakeholders involved? How did this affect the success of your solution?
A business analyst is generally a business domain expert who is well-versed in business processes to help business stakeholders identify and define the strategy behind the total solution. Business analysts may be experts in Six Sigma, Lean Manufacturing, the Capabilities Maturity Model Integration (CMMI), or other operational methodologies. They are generally technology-aware but focus more on the business aspects in problem solving and resolution. These individuals may be internal or external to the organization.
A business analyst will assist and direct the business stakeholder’s vision and direction into an actionable business plan.
The solutions architect will engage strategy skills when working with the business analyst to effectively design and apply appropriate technology around the actionable business plan, and to make certain that the solution is technically achievable within the required timeframe.
Exercises for Understanding
· The business analyst often represents the “voice of the customer.” Many of the critical decisions of a solutions architect require an unfiltered understanding of the customer’s needs. What can you do to make certain that you are obtaining the correct information that is the basis for your architectural decisions?
Larger organizations may have an enterprise architect. If this isn’t the case, the role is generally assumed by one or more individuals (either the CTO, CIO, or both). The enterprise architect is aware of the organization’s infrastructure, development capabilities, user adoption, and use of the organization’s systems, and often is a key link to technology product and service providers.
An enterprise architect assists the business stakeholders and business analyst in determining what parts of the business plan are possible with existing systems and what system enhancements are necessary.
The solutions architect maintains a close relationship with the enterprise architect, engaging technology breadth skills so that the enterprise architect can accurately assess and understand the organization’s development strengths and weaknesses.
Consider for Yourself
· An enterprise architect may be responsible for maintaining a set of organizational guidelines and standards. What if a solutions architect believes that it is in the best interest of the specific solution’s success to not follow the enterprise standards?
End users are the ultimate domain experts in an organization. The solution may enhance their effectiveness or redefine their roles as businesses evolve.
An end user’s adoption and use of a solution directly affects the overall business plan and strategy. Where there is alignment, there is success. Where there are gaps, issues are bound to exist.
The solutions architect must engage strategy skills with a keen understanding of the business plan and use effective communication skills when working with end users to architect a technology solution that optimally engages and supports them to meet the business plan’s goals.
The project manager is responsible for planning, communication, and project administration.
From a project management perspective, organizations may have a functional organizational structure, a project-based organizational structure, or a matrix organizational structure, which is a hybrid of the two. Solutions architects and project managers often find that they need to perform project-based roles in functional organizations. This means that staff (including the solutions architect) often have other concurrent responsibilities.
There are many different project management methodologies, which may be characterized by the amount of process associated with the methodology. Most organizations have standardized on one methodology. Determining the solution’s project management methodology may at times be outside of the architect’s control.
One of the most popular “process intensive” project management methodologies is supported by The Project Management Institute (PMI). PMI’s methodology is described in the Project Management Body of Knowledge (PMBOK). All PMI-certified project managers are expected to fully understand this PMI PMBOK. The PMI methodology emphasizes thorough upfront planning.
Work breakdown structures are a standard project management tool that the PMI methodology embraces. The solutions architect and project manager can use a work breakdown structure, as shown in Figure 1-2, for planning project scope. Some tools let you create dependencies at the time that you create your Work Breakdown Structure. But the PMI-recommended approach is to first focus on determining the tasks, add the dependencies, and then assign dates and resources to each task.
Figure 1-2. Work breakdown structure
Other organizations have adopted less prescriptive project management methodologies, such as Agile. A solutions architect should understand the benefits and constraints of the chosen project management methodology for the solution, because this may affect architectural decisions. For example, in a more prescriptive project management methodology, the solutions architect may need to create and thoroughly document a complete technical architecture upfront. In a more iterative project management methodology, designs may be continuously revised and replaced.
Ideally, even in an agile project, the high-level architecture is determined up front, and all the iterative designs fit into this architecture. The design at the end of an agile project is often substantially different than that at the end of a more process-intensive project. The architecture may also change as greater insight is gained during the solution life cycle.
At times, the solutions architect will be asked to take on the role of project manager during a project. This can put a project at risk because project management is time-consuming and demanding. Also, most architects do not have the same level of project management skills as full-time project managers. When this occurs, effective architecture generally diminishes.
The project manager coordinates budgets, schedules, and resources for the solution.
The project manager does not judge a solution’s architecture. The project manager needs to be able to answer questions such as: Are we on schedule? Are we on budget? Where do we need to modify the schedule? What resources are required to move forward?
The solutions architect engages process and tactics skills when supplying the project manager with appropriately summarized information related to solution architecture. Ideally, the solutions architect and project manager work together to determine how much information the solutions architect should provide.
Developers are the conduit between the architecture of the business plan and end users. A developer’s interaction with end users generally increases the developer’s understanding of domain knowledge.
Developers and their best practices directly affect the adoption, usability, and profitability of the solution.
The solutions architect will engage technology depth, leadership, and communication skills to establish a role with developers as a collaborator, mentor, listener, and visionary.
Operations will either reap the benefits or bear the burden of the solution’s architectural and developmental practices.
The operations team affects the longevity, profitability, and reliability of a solution through its ability to keep the solution effectively running to the end users’ satisfaction.
Solutions architects engage organizational dynamics and communication skills to best understand which solution performance, resource use, and stability health metrics the operations team wants to monitor and how security or system configuration changes will affect the solution. A solutions architect benefits from a good working relationship with the operations team by learning how to overcome operational flaws in current and future architectures.
The infrastructure architect has parallel and interdependent responsibilities with the solutions architect to align technology with the solutions business strategy and goals.
The infrastructure architect must understand the infrastructure requirements of the solution and evaluate policies that govern overall solution operation so that the solution adheres to regulatory requirements and is deployed with appropriate technologies in a responsible manner.
The infrastructure and solutions architects share many of the same architectural skills. They must effectively apply these skills when working with each other.
Infrastructure architects are a valued collaborative resource to solutions architects in day-to-day development roadblocks (especially with regard to configuration and security) in addition to infrastructure and deployment matters. However, poor communication between the solutions and infrastructure disciplines in an organization often result in budget and timeline overruns and missed business plan goals. For example, the gap for the Development and Test phase shown for the infrastructure architect in Figure 1-1 is an unfortunate reality. Too often, infrastructure architects are part of the overall design and are responsible for the infrastructure deployment but are left out of the development phase.
Consider for Yourself
· Reflect on a past project that did not deploy smoothly. At what time was the infrastructure team involved? How would you modify that today?
The solutions architect succeeds through a mutual understanding of business strategy and goals, and by driving actionable results around a business plan through effective engagement with all involved in solution development and delivery.
The goal of the solutions architect is to develop solutions that support the business plan. As such, you must identify and apply appropriate technologies around the business plan to foster a solution that meets business plan goals through user adoption, productivity, and/or financial gains.
To Learn More
Check out the Project Management Institute Web site, www.pmi.org. PMI’s Project Management Professional (PMP) certification is required to be a project manager at many organizations. There are Project Management Institute chapters in many larger cities.
Lesson Wrap Up
The solutions architect takes the time to understand the roles and responsibilities of each of the solution team’s members. Consider how to most effectively interact with each of these team members at the appropriate times throughout the total solution life cycle.
Elements of the next three topics apply directly to skills in the strategy competency, because they often identify activity before a solutions architect’s engagement, but they serve to provide background and understanding to strengthen communication and organizational dynamics skills with regard to executive management
Topic 1: Business Strategy Planning
Solutions architects are comfortable with methodologies and frameworks that help them to work more efficiently or more effectively. In a similar way, the people in an organization charged with strategic planning have a set of analytical tools to help them create and communicate business strategy.
Just as a business stakeholder who has invested the time to learn how to read a UML diagram or an entity relationship diagram can engage more deeply in system design, solutions architects who are comfortable with strategic business tools have greater organizational clarity and are able to explain the business strategy of their organization. Understanding strategic business tools can also help solutions architects balance the needs of the various stakeholders as they make architectural decisions.
As organizations move from strategy to execution, they may use various tools at different points in the process, as shown in Figure 2-2.
Figure 2-2. From strategy to execution
Business schools and business literature teach a large number of strategic planning tools with overlapping capabilities. In this lesson, we provide an overview of two tools that are both popular and non-proprietary: the strategy map and the strategy canvas.
From a business value perspective, most organizations at any point are usually focused on one or two goals:
· Increasing sales.
· Increasing their operational ability to deliver what they have already sold (faster, at a lower cost, at a higher quality, and so on).
The strategy canvas is a tool that is aimed at increasing sales and margins. The strategy map is a tool that is targeted at focusing on the critical operational processes for an organization.
A solutions architect does not need to be an expert in these tools, but being able to read or even help create a strategy map or a strategy canvas is a skill that many organizations value. In addition to understanding how to use these tools, it is important that solutions architects also become aware of other tools and techniques (not covered in this discussion) that their organization uses to achieve operational excellence. These might include Lean Six Sigma, Total Quality Management (TQM), and the Capability Maturity Model Integration (CMMI).
Consider for Yourself
· Which is more important for your organization today: selling more or delivering on what has already been sold?
· Does your organization have a strategic plan? If so, have you read it? Some organizations are unwilling to share strategic plans, especially with external resources. Consider asking if the strategic plan can be made available to you.
· What business tools does your organization use for planning and communicating its strategy?
Topic 2: Strategy Maps
An organization chooses strategic priorities that it believes will create the most business value. A solutions architect who understands these strategic priorities can make better decisions.
Strategy maps are a business tool that helps an organization to choose its most important strategic objectives. After these objectives are identified, the projects that are most likely to help achieve these objectives can be identified and prioritized. Therefore, an organization that uses a tool like a strategy map to plan and communicate its strategic objectives is more likely to have its people working on those projects that contribute the most value.
We will start by looking at an example of a strategy map, as shown in Figure 2-3, based on an example in Norton and Kaplan’s book Strategy Maps. This airline’s leadership team has decided that an important way for it to achieve its financial goals is to focus on decreasing the amount of time that airplanes spend at terminal gates. The arrows show causality between strategic objectives. For example, “If we have faster ground turnaround time, we will have more on-time service and can offer lower prices. In turn, these will help us to both keep our existing customers and get more new customers.”
Figure 2-3. A strategy map for increased airline profits
Before you create a strategy map, your organization needs to first identify at least one thematic goal. Patrick Lencioni defines a thematic goal as: “The overarching priority of a team during a given period of time. It serves as a rallying cry for the team and often helps align other parts of the organization.”
Exercises for Understanding
· What is the thematic goal for the airline in Figure 2-3?
Next, you need to determine the strategic objectives that will best achieve the thematic goal. These strategic objectives should be grouped around a set of perspectives, based on first asking and then answering each of the following four questions:
· Financial perspective: What financial steps are needed to ensure the execution of our strategy?
· Customer perspective: Who are our customers, and what is our value proposition in serving them?
· Internal (operational processes) perspective: To satisfy our customers, what processes must we excel at?
· Employee learning and growth perspective: What capabilities and tools do our employees need to help them execute our strategy?
Organizations then determine which are the most important strategic projects and initiatives that map to each identified strategic objective. Most organizations also have many operational and regulatory projects and initiatives that need to be done.
Strategic planning tools, such as strategy maps, prioritize IT solution ideas. The organization that created the strategy map in Figure 2-3 determined that its most important IT investment is a crew scheduling system. The solutions architect that helps build this crew scheduling system is working on activities that are aligned with the strategic goals of the organization and can identify those IT investments that will most benefit the organization.
Consider for Yourself
· Does your organization, business unit, or team have specific thematic goals that everyone understands? Do you think working for an organization with consensus around shared thematic goals has an effect on a solution architect’s ability to make the best decisions?
· Suppose that you are the solutions architect for a customer extranet. Your team’s solution has tough deadlines and limited resources. What if your company’s strategy focuses on reducing operational costs? How might this affect your architectural decisions?
· Now, image that your company focuses instead on providing a better customer experience? Might this lead to different architectural decisions?
· Do you think that the company—and your solution—should put equal effort into both reducing operational costs and delivering a better customer experience?
Exercises for Understanding
· Create a strategy map that shows how a solution that you have worked on ties back to a specific strategic objective. Can you show how this strategic objective, in turn, ties back to a financial objective? Was there a clear thematic goal that was understood by everyone on your team?
To Learn More
· Lencioni, Patrick. Overcoming the Five Dysfunctions of a Team. San Francisco: Jossey-Bass, 2005.
· Kaplan, Robert S. and David P. Norton. “Having Trouble with Your Strategy? Then Map It.” Harvard Business Review. September/October 2000.
· Kaplan, Robert S. and David P. Norton. The Balanced Scorecard: Translating Strategy into Action. Boston: Harvard Business School Press. 1996.
· Kaplan, Robert S. and David P. Norton. The Strategy-Focused Organization: How Balanced Scorecard Companies Thrive in the New Business Environment. Boston: Harvard Business School Press. 2001.
· Kaplan, Robert S. and David P. Norton. Strategy Maps: Converting Intangible Assets into Tangible Outcomes. Boston: Harvard Business School Press. 2004.
· Niven, Paul R. Balanced Scorecard Step-by-Step: Maximizing Performance and Maintaining Results. Hoboken: John Wiley & Sons. 2002.
· Niven, Paul R. Balanced Scorecard Step-by-Step for Government and Nonprofit Agencies. Hoboken: John Wiley & Sons. 2003.
· Niven, Paul R. Balanced Scorecard Diagnostics: Maintaining Maximum Performance. Hoboken: John Wiley & Sons. 2005.
· Balanced Scorecard Collaborative Web site. http://www.bscol.com/.
· Carnegie Mellon University’s Software Engineering Institute’s CMMI Web site. http://www.sei.cmu.edu/cmmi/.
Topic 3: Strategy Canvas
Blue Ocean Strategy is a body of knowledge by W. Chan Kim and Renée Mauborgne that describes an analytical framework for innovation. A profitable organization pays attention to both top-line growth (increasing sales and margin) and bottom-line cost management (operational excellence). A strategy canvas is a tool that is part of the Blue Ocean Strategy analytical framework, which helps identify new areas for top-line growth.
Organizations that focus strictly on bottom-line cost management benchmark their competition, and then they strive to “do more for less” across the factors of competition. Kim and Mauborgne argue that this leads to a crowded market—a blood red ocean of intense competition and little hope for improving sales or profitability. Blue Ocean Strategy argues that the path to sales and profitability is to capture and create new market spaces. Their process for identifying a new mass of buyers for an organization’s products or services also requires determining what to reduce and what eliminate.
Kim and Mauborgne’s process is to ask:
· Who are you competing against?
· What are the factors of competition (in terms of buyer value or level of investment)? For each factor of competition, then ask:
· Which factors should be raised well above the industry’s standard?
· Which factors should be reduced well below the industry’s standard?
· Which of the factors that the industry takes for granted should be eliminated?
· Which factors should be created that the industry has never offered?
These factors are then charted out as a value curve on a strategy canvas, as shown in Figure 2-4.
Eliminating factors of competition is often the most difficult task. Many technologists love to build things, and to add value by incorporating new features. Blue Ocean Strategy argues that if you eliminate new features that a mass of buyers does not value, you can simultaneously reduce costs and increase buyer value.
Exercises for Understanding
· What are the value factors that define how your product or service competes? Whom do you see your organization competing against?
Contoso Hotels is a European hotel chain that entered a crowded market of one-star (budget) and two-star (luxury) hotels. Their competitors were clustered in one of two value curves (shown as red and green in Figure 2-4) around the factors that the hotel industry competes on. These factors include restaurants, architecture, room size, and price. Contoso targeted a group of buyers who just wanted a clean, quiet room at a reasonable price. The blue curve in Figure 2-4 depicts their decision to offer inexpensive rooms that are quiet, clean, and have very comfortable beds. This resulted in profit margins and occupancy rates that were above industry average.
Figure 2-4. Contoso Hotels strategy canvas
Consider for Yourself
· How could you use a strategy canvas to determine the value factors for a new software solution?
· Could you use a strategy canvas to help with a buy-versus-build or “vendor shootout” on a portal or enterprise resource planning (ERP) system? What might the different value curves be for each of these scenarios? What would the value factors be?
A solutions architect that uses these business tools can better understand and communicate the organization’s strategy. It also helps the solutions architect to build a deeper understanding of the perspectives of the other stakeholders who used these business tools to collaboratively create the organization’s strategy.
To Learn More
· Kim, W. Chan and Renée Mauborgne. Blue Ocean Strategy: How to Create Uncontested Market Space and Make Competition Irrelevant. Boston: Harvard Business School Press. 2005. ISBN 1591396190.
· Kim, W. Chan and Renée Mauborgne. Blue Ocean Strategy: Go where the profits and growth are—and where the competition isn’t. Blue Ocean Strategy Web site. http://www.blueoceanstrategy.com/downloads/bos_web.pdf.
Topic 4: Investment Calculations
Solutions architects must know how solutions are valued, so they can create the highest value solutions. A solutions architect who can speak in terms of a solution’s payback period or total cost of ownership (TCO) will also gain greater credibility and trust with his or her stakeholders.
This topic focuses on the financial elements of a solution that enhance skills in the strategy and process and tactics competencies as well as to provide further background and understanding to strengthen communication and organizational dynamics skills with regard to executive management and business analysts.
There are three general categories for which a solution can be justifiably funded:
· Hard savings. Actual financial gains realized by cost reductions and/or increased revenue. Some examples are cost savings due to reduction in legacy platform maintenance, reduction in workforce employment costs, elimination of capital expenditure, and new sales of added functionality. This form of justification speaks loudest to financial stakeholders.
· Soft savings. Financial gains realized by improvements in operational efficiency. Examples include accomplishing tasks in less time, increased accuracy in data management and presentation, and increased solution adoption. This form of justification is rarely acceptable to financial stakeholders unless they can be translated into some form of hard savings. They often are used to add color to cost justification as intangibles.
· Regulatory or policy. The work must be completed to meet compliance with laws or policies. Estimating the cost of compliance, instead of justifying it, is what matters here.
Taking the above categories into account often leads a solutions architect into a buy-versus-build decision scenario. Many package and framework tools now exist to facilitate functionality such as collaboration, workflow, integration, presentation, and so on. No out-of-the-box product will take a solution to 100 percent satisfaction of requirements, but many of them may deliver 85-90 percent with substantially less investment. This speaks loudly to financial stakeholders who are concerned about the time and cost overruns historically associated with build scenarios.
Another component that must be considered is the cost to operate and maintain the solution after it is deployed. This can sometimes exceed the cost to develop a solution.
Return on investment (ROI) is used to evaluate the efficiency of the investment for the solution or to compare the efficiency of a number of different alternatives. To calculate ROI, the benefit (return) of an investment is divided by the cost of the investment. The result is expressed as a percentage or a ratio.
(Gain from Investment – Cost of Investment)
Cost of Investment
Payback period is the length of time required to recover the cost of the investment for the solution.
Payback Period =
Cost of Investment (TCO)
Annual Cash Inflows (Hard not Soft)
In one organization, a payback period of three years might be considered acceptable; another organization may not approve projects with payback periods over six months.
Further investment analysis will include the cost to operate and maintain the solution over the life expectancy for the solution. This is known as the total cost of ownership (TCO).
More rigorous calculations exist, including asset depreciation and expense exist, but the following simple TCO calculation can be used to help detect whether a particular approach is a worthwhile investment.
Development Cost + (Yearly Operations & Maintenance * Solution Life)
Now, compare TCO/year to hard savings/year. If the TCO/year is less than the hard savings/year, one might consider a payback period that is outside normal tolerance.
Consider: A $100,000solution with $5,000/year in operations and maintenance expected to last five years. The solution is expected to have a hard savings of $30K per year.
Payback period = 4 years 2 months
TCO = $125K
TCO/year = $25K < $30K hard savings/year
This solution may still be viable in an organization with a payback period of four years since it will save $5,000 per year.
A solutions architect should know how to perform financial calculations like ROI, TCO, and payback period. If a solution will be approved only if it pays for itself in less than a year, the solutions architect may be able to make design decisions that make the solution’s implementation practical within that payback period constraint. Understanding these financial constraints may also help a solutions architect determine at an earlier point that it is not practical to move forward with a specific solution implementation idea.
Exercises for Understanding
· Take a recent project and calculate its payback period. Now, calculate (as best you can guess) the TCO. How does it compare over the solution life to the savings/year?
To Learn More
· Baseline online magazine. http://www.baselinemag.com/.
· CIO online magazine. http://www.cio.com.
· Investopedia Web site. http://www.investopedia.com.
A solutions architect who invests the time to understand his or her organization’s strategy makes better decisions that lead to solutions that deliver more business value. This allows the solutions architect to become a more trusted technical advisor. Solutions architects also understand that they need to be able to use recognized methods, such as ROI and TCO, to communicate out the business value of their solutions. This can also lead to being able to quantify the financial impact of different approaches to an architectural decision.
More senior solutions architects are seen as business technology advisors. This is particularly important in organizations that compete based on their ability to use technology effectively.
This lesson focuses on elements related to strengthening skills in the strategy competency. It is not necessary to be an expert in the specific example frameworks and methodologies being discussed; instead, it is important to gain experience using an enterprise architecture framework to map the business strategy of the organization to your solution and to learn to build, adopt, or adapt a methodology to provide predictability to IT and ensure repeatable success on IT projects.
Topic 1: Enterprise Architecture Frameworks
In this topic, we introduce enterprise architecture frameworks. The enterprise architect uses enterprise architecture frameworks to describe how an organization’s business strategy aligns to its processes, information systems, personnel, and sub-units. The relationship between the solutions architect and enterprise architect is described in Lesson 1 of this module.
The enterprise architecture framework documents the building blocks that make up all of an organization's information assets. These assets include all the systems across the organization's business units. From the enterprise architect's perspective, information assets include business plans, system performance and structure, and the related processes. Enterprise architecture frameworks organize, categorize, and define relationships between these information assets. Two common enterprise architecture frameworks are the Zachman Framework for Enterprise Architecture and The Open Group Architecture Framework (TOGAF).
The Zachman Framework defines a set of views that provide a high-level perspective of an organization’s information assets. This framework provides solutions architects with a broader view of how their solutions integrate with the rest of the organization’s information assets to mitigate the proliferation of application silos that often burden an organization. Silos happen when organizations develop redundant, overlapping, non-interoperable solutions. Ideally, with better perspective, organizations can share compatible solutions for recurring functionality.
The Zachman Framework has a classification scheme for descriptive representations of the enterprise. It is represented by a matrix of cells containing models (artifacts) describing the activities and functions of the organization. You can download this matrix, named “Enterprise Architecture: A Framework,” from The Zachman Institute for Framework Advancement Web site at http://www.zifa.com/framework.pdf.
The six columns of the Zachman matrix are divided according to what framework developer John Zachman refers to as interrogatives that define the enterprise: what (data), how (function), where (network), who (people), when (time), and why (motivation). The order of these columns does not matter.
The rows represent the perspectives of the enterprise. These perspectives are defined as scope (contextual), business model (conceptual), system model (logical), technology model (physical), detailed representations (out-of-context), and the functioning enterprise. Related roles are played by different actors within the enterprise: the planner, owner, designer, builder, and subcontractor. Some adopters have added a worker role to the functioning enterprise.
Each cell in the grid represents a specific enterprise artifact. A fully architected enterprise has an explicit representation that describes both the current and future activities related to that cell. All models in surrounding cells should be consistent with the artifacts in a particular cell. For an enterprise to have complete alignment of its business strategy to its systems, it must be completely efficient in its application of resources, priorities, and processes. Of course this is a theoretical goal, and not an actual physical outcome.
The solutions architect can best assist the enterprise architect role with the business model perspective by communicating how the solution architecture will impact the systems model, technology model, and detailed representations perspectives.
The Open Group Architecture Framework
The Open Group Architecture Framework (TOGAF) is a set of models and tools for developing a broad range of IT architectures. Instead of prescribing a specific set of enterprise architecture deliverables or views, TOGAF is designed to be used with whichever deliverables are considered most appropriate for a particular solution. TOGAF describes an example taxonomy of the views an architect might consider providing guidelines for making that choice.
TOGAF is designed to support:
· Business process architecture. This is mainly the business strategy, governance, organization, and key business processes.
· Data architecture. This is the structure of the organization’s logical and physical data assets and management resources.
· Applications architecture. This is the blueprint for the individual application systems, their interactions, and their relationships to the organization’s core business processes.
· Technology architecture. This is the logical software and hardware capabilities required to support the development of business, data, and application services (infrastructure, integration, standards, and so on).
TOGAF has three main parts:
· Architecture Development Method
· Enterprise continuum
· Resource base
The next sections describe each of these.
Architecture Development Method
This identifies how to derive an organization-specific enterprise architecture that addresses business requirements through architectural views. Architecture Development Method (ADM) links to practical case studies and guidelines on tools for architecture development. It consists of nine basic phases:
· Preliminary phase: Framework and principles. This phase involves getting everyone on board with the plan.
· Phase A: Architecture vision. This phase involves defining your scope and vision and map your overall strategy.
· Phase B: Business architecture. This phase involves describing your current and target business architectures and determine the gap between them.
· Phase C: Information system architectures. This phase involves developing target architectures for your data and applications.
· Phase D: Technology architecture. This phase involves creating the overall target architecture that you will implement in future phases.
· Phase E: Opportunities and solutions. This phase involves developing the overall strategy, determining what you will buy, build or reuse, and how you will implement the architecture described in phase D.
· Phase F: Migration planning. This phase involves prioritizing projects and developing the migration plan.
· Phase G: Implementation governance. This phase involves determining how you will provide oversight to the implementation.
· Phase H: Architecture change management. This phase involves monitoring the running system for necessary changes and determining whether to start a new cycle, looping back to the preliminary phase.
This is a virtual repository of all architectural building blocks and models that exist within and across enterprises. The enterprise continuum provides a context-independent way to describe, understand, and leverage architecture assets and artifacts. For example, the enterprise continuum’s consistent language makes it easier to leverage and re-use architectural assets across a supply chain.
This is a set of resources (guidelines, templates, backgrounds, and so on) that assist in the use of the TOGAF ADM.
TOGAF is a top-down framework that starts with the big picture and breaks it down into progressively smaller pieces. It is intended to be a generic method that works with any architecture and complements many bottom-up methodologies, such as the Rational Unified Process (RUP), which will be discussed in Topic 2.
Exercises for Understanding
Identify where in each of the enterprise architecture frameworks a solutions architect is deeply involved. Which framework best addresses the needs of your organization?
To Learn More
· Hoffman, Alex. “What is the Zachman Framework for Enterprise Architecture?” White paper. http://weblogs.asp.net/ahoffman/archive/2004/10/21/Reference_3A00_-What-is-the-Zachman-Framework-for-Enterprise-Architecture_3F00_.aspx.
· The Zachman Institute for Framework Advancement Web site. http://www.zifa.com.
· Chase, Nicholas Chase. “Introducing The Open Group Architecture Framework (TOGAF), Part 1: Understand TOGAF and IT architecture in today's world.” White paper. http://www-128.ibm.com/developerworks/ibm/library/ar-togaf1/. 2006.
· Harrison, David and Lou Varveris. “TOGAF: Establishing Itself as the Definitive Method for Building Enterprise Architectures in the Commercial World.” White paper. http://www.developer.com/design/article.php/3374171. 2004.
· Temnenco, Vitalie. “TOGAF or not TOGAF: Extending Enterprise Architecture beyond RUP.” White paper. http://www-128.ibm.com/developerworks/rational/library/jan07/temnenco/index.html. 2007.
· The Open Group Architecture Forum Web site. http://www.opengroup.org/architecture/togaf.
· Sessions, Roger. “A Comparison of the Top Four Enterprise-Architecture Methodologies.” http://msdn2.microsoft.com/en-us/library/bb466232.aspx.
Topic 2: Methodologies
A solutions architect must manage change and complexity. When a solutions architect becomes responsible for architecting more complex solutions, the design and development requires additional structure to be successful. As the number of function points (the amount of business functionality an information system provides to an end user) increases, the higher the risk of delays or even cancellation. Mitigating these risks requires a structure composed of checks and balances. This imposed structure is called a methodology.
In this topic, we will introduce several popular methodologies, including the Rational Unified Process (RUP), Microsoft Solution Framework (MSF), and Agile.
Generally, all solution methodologies provide structure around the following process activities:
· Gathering requirements.
· Describing the software through specification.
· Architecture of a system to meet the requirements.
· Implementation (coding).
· Software training and support.
When these process activities are performed sequentially, it is known as a waterfall process. A waterfall methodology may fail catastrophically when a design flaw is not discovered until a solution is being deployed. Figure 3-3 shows the cascading effect of exponential costs using this form of methodology.
Figure 3-3. Traditional waterfall model
Most modern methodologies adopt some form of iterative, risk-driven development. In a year-long project that follows a waterfall methodology, all the requirements are gathered first. Then all of the design is complete. Then all of the code is written. Then the code is tested. In an iterative process, the year-long project is broken down into a smaller set of iterations (or time blocks). While iterative processes have become standard, there is little consensus on the best length for each iteration. For example, there might be three iterations, each with its own requirements, design, coding, testing, and delivery. In an extreme example, extreme programming (XP) recommends week-long iterations.
The methodology that best fits a solution can depend on several factors, including target environment, security, contract type (for outsourced solutions), and degree of user input required.
While multiple agile software development methods exist, the Agile Alliance is the governing body behind the majority. Most agile methods attempt to minimize risk by developing software in short iterations, which typically last one to four weeks with distinct deliverables.
Each iteration is like a miniature waterfall process software project that includes all the tasks necessary to release the mini-increment of new functionality:
· Requirements analysis
While not always the case, an agile methodology used for a software project intends to be capable of releasing new software at the end of each iteration. At this time, the team always reevaluates project priorities.
Agile methods emphasize real time communication—preferably face-to-face—instead of written documents. Most agile teams are co-located during the entire software development life cycle.
The Agile Alliance created the Agile Manifesto. As stated at www.agilemanifesto.org, its four tenets are to value:
· Individuals and interactions over processes and tools.
· Working software over comprehensive documentation.
· Customer collaboration over contract negotiation.
· Responding to change over following a plan.
Like the other methodologies overviewed, Agile is governed by a set of principles:
· The highest priority is to satisfy the customer through early and continuous delivery of valuable software.
· Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
· Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
· Business people and developers must work together daily throughout the project.
· Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
· The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
· Working software is the primary measure of progress.
· Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
· Continuous attention to technical excellence and good design enhances agility.
· Simplicity—the art of maximizing the amount of work not done—is essential.
· The best architectures, requirements, and designs emerge from self-organizing teams.
· At regular intervals, the team reflects on how to become more effective, and then it tunes and adjusts its behavior accordingly.
Extreme Programming (XP) is one very lightweight form of Agile. XP is based on the five values:
XP advocate Kent Beck has identified the following list as the most important agile practices:
· The planning game. This involves quickly determining the scope of the next release by combining business priorities and technical estimates. As reality overtakes the plan, update the plan.
· Small releases. This involves putting a simple system into production quickly, and then releasing new versions on a very short cycle.
· Metaphor. This involves guiding all development with a simple shared story of how the whole system works.
· Simple design. This involves designing the system to be as simple as possible at any particular moment. Extra complexity is removed as soon as it is discovered.
· Testing. This involves having programmers continually write unit tests, which must run flawlessly for development to continue. Customers write tests demonstrating that features are finished.
· Refactoring. This involves having programmers restructure the system without changing its behavior to remove duplication, improve communication, simplify, or add flexibility.
· Pair programming. This involves writing all production code with two programmers at one computer.
· Collective ownership. This involves letting anyone change any code anywhere in the system at any time.
· 40-hour week. This involves working no more than 40 hours a week as a rule. Never work overtime a second week in a row.
· On-site customer. This involves including a real, live user on the team available full-time to answer questions.
· Coding standards. This involves having programmers write all code in accordance with rules emphasizing communication through code.
One of the most notable practices is that of pair programming, which requires two programmers to participate in a combined development effort at one workstation. The person doing the typing is known as the driver while the person who is guiding is known as the navigator. It is suggested for the two partners to switch roles at least every half-hour or after a unit test is made. It is also suggested to switch partners at least once a day.
Scrum is another popular agile process for managing software development. Scrum is a rugby term that describes a way to restart the game after an interruption, such as after a minor foul. In an Agile scrum, projects progress through a series of month-long iterations called sprints.
The work to be done on a scrum project is listed in the Product Backlog, which is a list of all desired changes to the product. At the start of each sprint, a Sprint Planning Meeting is held during which a Product Owner prioritizes the Product Backlog and the Scrum Team selects the tasks they can complete during the upcoming sprint. These tasks are then moved from the Product Backlog to the Sprint Backlog.
Throughout the sprint, a brief daily meeting called the Daily Scrum keeps the team focused and on-task. At the completion of each sprint, the team demonstrates the project functionality at a Sprint Review Meeting. The entire process is detailed at www.controlchaos.com.
Rational Unified Process (RUP)
The Rational Unified Process (RUP) is an adaptable process framework intended to be customized by development organizations and software project teams that will select the elements of the process that are appropriate for their needs. It is also a software process product, originally developed by Rational Software, and now available from IBM.
In RUP, a solution is designed and built in a succession of incremental iterations. This allows testing and validation of design ideas, as well as risk mitigation, to occur earlier in the life cycle. The RUP life cycle organizes the tasks into phases and iterations.
A project has four phases:
The next sections describe each of these.
In this phase, the business plan, including the business context, success factors, and financial forecast, is established. Artifacts typically include a UML use case model, project plan, risk assessment, and project requirements documents. The project iterates and moves to the next phase when the life cycle objective milestone is passed:
· Credibility and stakeholder concurrence on scope, cost, and schedule estimates.
· Requirements are understood as evidenced by the relevance of the primary use cases.
· Acceptance of any architectural prototype(s) developed.
· Acceptance of actual expenditures versus planned expenditures.
In this phase, the problem domain analysis occurs and the architecture of the project is established. The project iterates and moves to the next phase when the life cycle architecture milestone is passed:
· Use cases and actors have been identified and most of the use-case descriptions are developed.
· Description of the software architecture and software system development process is documented.
· Business case and risk list is documented.
· A development plan for the overall project is documented.
· Prototypes that demonstrate technical feasibility are developed.
In this phase, the development of components and other features of the system is broken into multiple construction iterations producing the first external release of the project marking the Operational Capability Milestone.
In this phase, the resulting product moves from the development organization to the end user. The activities of this phase include training end users and maintainers and beta testing of the system to validate it against the end users' expectations. The project iterates until the quality level set in the Inception Phase is met marking the Product Release Milestone.
There is a graphic that shows the Rational Unified Process effort by disciplines in the white paper, “What Is the Rational Unified Process?”, which can be found at http://www-128.ibm.com/developerworks/rational/library/content/RationalEdge/jan01/WhatIstheRationalUnifiedProcessJan01.pdf. Please refer to Figure 2 on page 4 of this white paper.
Iterations in each of the four phases have tasks that are categorized into the following nine disciplines, as shown in the referenced white paper diagram.
· Business modeling. This discipline explains how to describe a vision of the organization in which the system will be deployed and how to then use this vision as a basis to outline the process, roles, and responsibilities.
· Requirements. This discipline describes what the system should do through required functionality documentation.
· Analysis and design. This discipline produces a design model that serves as an abstraction of the source code. This design model consists of design classes structured into packages and subsystems with well-defined interfaces. The components (design classes, packages, and subsystems) of this design model will be built during the Implementation discipline.
· Implementation. This discipline defines the organization of code in terms of subsystems organized in layers, classes, and objects in terms of components (source files, binaries, executables, and others); unit tests of developed components; and the integration of components into an executable system.
· Test. This discipline iteratively verifies the following in terms of reliability, functionality, application performance, and system performance:
· Interaction between objects.
· Proper integration of components.
· Adherence to requirements.
· Properly managed defects.
· Deployment. This discipline pproduces product releases that deliver the solution to its end users providing necessary training.
· Configuration and change management. This discipline deals with three specific areas of management:
· Configuration management of artifacts such as documents and models keeping track of their interdependencies.
· Change request management to keep track of proposals for change.
· Status and measurement management to report on the progress of the project.
· Project management. This discipline produces a coarse-grained Phase Plan, which describes the entire project from a set of monitoring plans (measurement, risk management, problem resolution, and acceptance) and a series of fine-grained or Iteration Plans, which describe the iterations as a set of time-sequenced activities and tasks with assigned resources containing task dependencies.
· Environment. This discipline provides the software development organization with the software development environment processes and tools that will support the development team by:
· Preparing the environment for the project.
· Preparing the environment for an iteration.
· Supporting the environment during an iteration.
RUP is an adaptive set of tools the solutions architect chooses and configures to meet the organization’s development needs.
Exercises for Understanding
· Identify which players in the total solution life cycle the solutions architect interfaces with during each RUP project phase.
· “RUP Light.” Create your own modified version of RUP by choosing only those RUP components that would be most useful for a smaller project that you have been involved with.
The Microsoft Solutions Framework
The Microsoft Solutions Framework (MSF) is an integrated system of process guidance that embraces both agile and formal methodologies and provides a framework to implement a customized solution for a wide variety of projects. MSF is now an integrated product offering from Microsoft as part of the Visual Studio® Team System. There are two forms of process guidance currently available:
· MSF for CMMI Process Improvement. This guidance provides rich connections to the Capability Maturity Model Integration (CMMI) process to help organizations implement mature software development practices.
· MSF for Agile Software Development. This guidance provides for iterative software development in the enterprise using features such as risk management, release management, and design for operations. As the name implies, MSF for Agile does actually adopt and adapt agile aspects to its process. However, it is a separate methodology than what is considered general or generic Agile.
This overview will focus on MSF for Agile Software Development, which is based on the following concepts:
· Cycles and iterations. Product definition, development, and testing occur in overlapping iterations, resulting in incremental completion of the project. Different iterations have different foci as the project approaches release. Small iterations reduce the margin of error in estimates and provide quick feedback about the accuracy of project plans. Each iteration should result in a stable portion of the overall system.
· Governance. Control of time and cost are relative to the flow of value. MSF for Agile Software Development defines five governance checkpoints, each of which focuses on a specific question to answer (see Figure 3-5). The activities and work streams leading to the checkpoints are called tracks. Do not confuse the tracks for governance with the organization of work that is grouped in iterations and the finer cycles within.
Figure 3-5. MSF Governance
This describes the approach to structuring people and their activities to enable project success. The fundamental principles of the MSF team model are:
· Team of peers with clear accountability, shared responsibility, and open communications. Each role is accountable for a specific share of the quality of the overall solution.
· Advocacy for all key constituencies who must be represented on a successful software project. Every perspective is represented to provide the checks and balances that prevent errors of omission and lopsided decisions.
· Stretch to fit to the scale necessary for the specific project. Constituencies may be combined in small teams or further refined as teams scale for larger projects.
These are directly incorporated for handling quality of service (QoS) requirements, such as performance and security using a context-driven approach to determine how to operate the project. The governing principles are:
· Partner with customers. This means team decisions are based on a sound understanding of the customer’s business and on active customer participation in project delivery.
· Work toward a shared vision. This means adopting a shared vision to align the team around a common goal and set the customer’s expectations.
· Deliver incremental value. This means that through frequent delivery, process and infrastructure are proven and improved and risks, bugs, and missing requirements are detected early.
· Invest in quality. This means every team member assumes responsibility for the quality of the product. Responsibility for quality cannot be delegated from one team member to another team member or function.
· Empower team members. This means each member is empowered to deliver on their own commitments and has confidence that, where they depend on the commitments of other team members, that these will also be met.
· Establish clear accountability. This means the team of peers combines a clear line of accountability to the stakeholders with shared responsibility for overall success. Within the team, each role is accountable to the team itself (and to their own respective organizations) for achieving their role’s quality goals.
· Learn from all experiences. This means each project and iteration within the project creates a learning opportunity through honest feedback and reflection.
· Foster open communications. This means an open and honest approach to communications, both within the team and with key stakeholders, to promote a free-flow of information, reduce misunderstandings and wasted effort, and ensure that all team members can reduce uncertainties surrounding the project.
· Stay agile, adapt to change. This means that by assuming things are continually changing and that it is impossible to isolate a project from these changes, the team model ensures that all core roles are available throughout a project so they can contribute to decisions arising from these changes.
A culture that fosters successful projects requires a mindset, which is a collection of values that determine how individuals will interpret and respond to situations. There are nine values in MSF:
· Focus on business value.
· Advocate for your constituency.
· Take pride in workmanship.
· Deliver on your commitments.
· Look at the big picture.
· Foster a team of peers.
· Practice good citizenship.
· Learn continuously.
· Internalize qualities of service.
Several innovations are identified by the team model:
· Separation of governance from capacity. This separates the corporate and project governance for allocation of resources to projects. It also separates the value the project seeks to create from the operational management of functional capacity, throughput, and its variation.
· Lean project management. This uses the flow of value created through a life cycle of progressive functional steps by tracking, managing, and monitoring the queue of work at each step using a cumulative flow chart developed for Lean Manufacturing.
· Trustworthy transparency. This leverages Visual Studio Team System to track progress of work items and link that progress to check-in policies for items stored in version control. The reporting in Visual Studio Team System provides transparency on progress.
· Qualities of service. This elevates non-functional requirements in the project scope through the definition of QoS requirements that are planned and scheduled from the beginning and developed into the product as recognized value within the required scope.
· Constituency- and event-driven risk management. This combines day-to-day event-driven risk monitoring with the team model, which treats risks as future special cause events with a probability and impact of occurrence.
· Continuous adoption curve – agile through CMMI. This provides acceleration to CMMI Level 3 by developing a Deming-based quality assurance approach to the CMMI process guidance and by incorporating all the guidance within that approach.
A team of peers is brought together to represent the entire set of constituents that are involved with the production, use, and maintenance of the product. Each team member, or role, is accountable for representing the specific needs of its constituencies and none is more important than another. Together, these views provide the necessary checks and balances to ensure that the team produces the right solution. The roles are depicted in Figure 3-6.
Figure 3-6. MSF Roles
Work items are used to track assignment and state of work. Five types of work items are assigned to track work:
· Scenario. This work item records a single path of user interaction through the system.
· Quality of service requirement. This work item documents characteristics of the system, such as performance, load, availability, stress, accessibility, serviceability, and maintainability.
· Task. This work item communicates the need to do some work.
· Bug. This work item communicates that a potential problem exists or has existed in the system.
· Risk. This work item documents and tracks the technical or organizational risks of a project.
MSF provides two completely functional process templates/frameworks for process innovation out-of-the-box, but it is also extensible to allow solutions architects to create custom process templates for individual projects.
Exercises for Understanding
· Describe and give an example how you would use Governance to control Cycles and Iterations from becoming runaway.
Capabilities Maturity Model Integration (CMMI)
CMMI is not a software development process methodology; it is a software process improvement methodology that can make any process methodology better.
As Thomas Davenport notes, “CMM(I) is a process management standard. It doesn’t require that organizations follow a particular process for software development… only that they have processes in place for addressing quality issues.”
CMMI defines five levels, with every software organization starting out at level 1. Organizations get better by self-assessment. Software companies that have achieved CMMI level 5 are regarded by many customers as being better able to deliver higher quality solutions.
Determining the Appropriate Methodology for Your Solution
Choosing the appropriate methodology for your solution may require some tradeoffs.
Software development is a balancing act between defined current needs and undefined future needs. Specifically, choosing the right methodology requires facing the difficulty of striking the right balance between the agility of individual teams and providing enough process to support cross-team collaboration. In general, the more prescriptive process-intensive methodologies add overhead in the form of process and documentation that may prove useful for the future needs of ongoing collaboration and the layering on of new requirements. Figure 3-10 categorizes the methodologies reviewed.
Project life cycle
Rational Unified Process (RUP)
Microsoft Solutions Framework CMMI
Agile Scrum and Microsoft Solutions Framework Agile
Figure 3-10. Choosing methodologies based on process and management matrix
Other factors that can provide the solutions architect with guidance in selecting a methodology include:
· Project team size. Larger projects are less suitable for agile methodologies. To apply an agile methodology to a project that requires tens or hundreds of developers may require breaking the project up into smaller pieces.
· Application complexity. Again, greater complexity often mandates more prescriptive methodologies.
· Experience level of application team. More experienced teams are often more effective with empirical methodologies.
· Mandated requirements. For example, solutions developed for the pharmaceutical industry typically require more process and documentation.
A solutions architect must remember that methodology does not remove the need to think hard about a solution’s challenges. As Rosenberg and Scott note in Use Case Driven Modeling with UML, a Practical Approach: "When methodology becomes religion (Methodology) and is followed by rote rather than being followed because it leads to the desired result, major problems occur and projects fail. Software cannot be developed on autopilot—it requires thought."
Exercises for Understanding
· We’ve discussed RUP, MSF, and agile methodologies. Under which circumstances would you advocate each of these methodologies over the other two?
· Which MCA competencies do you see being used most by the solutions architect with regard to frameworks and methodologies?
To Learn More
· Greenfield, Jack and Keith Short. Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. Indianapolis: Wiley. 2004.
· Jones, Capers. "Why Flawed Software Projects Are Not Cancelled in Time." Cutter IT Journal. Vol. 16, No. 12. 2003.
· IBM Rational Unified Process. Web site. http://www-306.ibm.com/software/awdtools/rup/.
· Kruchten, Philippe. “What Is the Rational Unified Process?” White paper. http://www-128.ibm.com/developerworks/rational/library/content/RationalEdge/jan01/WhatIstheRationalUnifiedProcessJan01.pdf. 2001.
· Microsoft Solutions Framework Web site. http://msdn2.microsoft.com/en-us/teamsystem/aa718795.aspx.
· MSF for Agile Software Development Process Guidance. .
· MSF for CMMI® Process Improvement. .
· Guckenheimer, Sam and Juan J. Perez. Software Engineering with Microsoft Visual Studio Team System. Addison-Wesley Professional. 2006.
· Agile Alliance Web site. http://www.agilealliance.org/.
· Manifesto for Agile Software Development Web site. http://www.agilemanifesto.org/.
· Murphy, Craig. “Adaptive Project Management Using Scrum - Part 1.” White paper. http://www.methodsandtools.com/archive/archive.php?id=18. 2004.
· SCRUM It's About Common Sense Web site. http://www.controlchaos.com/.
· Beck, Kent and Cynthia Andres. Extreme Programming Explained: Embrace Change (2nd Edition) (The XP Series). Addison-Wesley Professional. 2004.
· Davenport, Thomas H. “The Coming Commoditization of Processes.” Harvard Business Review. 2005.
· Wake, William C. Extreme Programming Explored. Addison-Wesley Professional. 2001.
· Schwaber, Ken and Mike Beedle. Agile Software Development with Scrum. Prentice Hall. 2001.
· Agile Journal Web site. www.agilejournal.com.
· Agile Data Web site. http://www.agiledata.org.
· CMMI Web site. www.sei.cmu.edu.
· Caputo, Kim. CMM Implementation Guide: Choreographing Software Process Improvement. Addison-Wesley Professional. 1998.
Topic 3: Development Models
This topic focuses on elements related to strengthening skills in both the process and tactics and technology breadth competencies in that development models are prominent architectural concepts used to design a solution that meets operational requirements, such as scalability, maintainability, security, reliability, extensibility, flexibility, availability, and manageability.
In this topic, you will learn about the development models that use Test-Driven Development (TDD), Model-Driven Development (MDD), and design patterns. A solutions architect that understands when and how to apply TDD, MDD, and design patterns to the solution will be able to architect higher quality solutions more quickly.
Test-Driven Development (TDD)
TDD is a model for software development that resulted from agile principles. TDD iterates through first writing a set of test cases, and then implementing only the code needed to pass each test case. In TDD, developers write test harnesses that support their code. Even though the “throw-away” test harness code may be twice as large as the production code, TDD’s advocates have found that the imposed discipline of TDD means that the production code is delivered more quickly. Another benefit of TDD is that when changes are made to solutions (to correct defects or meet business requirements), the test harness makes it easier to safely verify that all of the related the code is thoroughly tested.
Here are the process steps for TDD:
· Test list. When starting a new task or feature, you brainstorm a list of tests describing the requirements unambiguously indicating the scope of the activity
· Red/green/refactor. This step defines the process for implementing each test in the test list. The goal of this process is to work in small, verifiable steps that provide immediate feedback:
1. Write the test code.
· Compile the test code. (It should fail because you have not implemented anything yet.)
· Implement just enough to compile.
· Run the test and see it fail.
· Implement just enough to make the test pass.
· Run the test and see it pass.
· Refactor for clarity and to eliminate duplication. Refactoring is described below.
· Repeat from the top.
Test-driven development has two rules:
· Do not write code without having failed an automated test. Your automation could take the form of a test harness written in the same language as the code. Because the test is written before the code, it should always fail the first time that it is written.
· No code should be duplicated in the program.
Tests can be categorized based on who produces the test:
· Customer tests. These tests are produced by customers who specify the functionality. Sometimes regarded as acceptance or functional tests, customer tests specify the functionality from a business or customer facing perspective.
· Developer tests. These tests are produced by developers who implement the functionality. Tests focused on technology are often regarded as unit tests.
A common practice in TDD is that of simple design. When authoring code to satisfy the business requirements, produce no less (to meet the requirements) and no more (added complexity in the form of additional functions, abstract classes, etc. that nobody ever asked for).
Another common practice in TDD is that of refactoring. Refactoring is defined as improving the design of existing code without changing its external behavior. Without refactoring, a solution’s design tends to decay under the stress of applying new changes over time. This is seen in the many applications that are “frozen” in production or retired because each new change creates unacceptable breakages.
Refactoring advocates a set of small design changes that rework an application into well-designed code. TDD makes refactoring safer, because TDD’s automated test harness provides a means for more economically testing the refactoring’s changes to the code base.
Consider for Yourself
· A solutions architect, when promoting and enforcing the elimination of code duplication through the use of inheritance, will often receive resistance from developers due to the interruption of their implementation flow. How do you convince them time invested now saves more time required?
· In design walkthroughs with developers, solutions architects should require developers to explain how they will test each feature that they plan to code. Developers should unit test their own code. Solutions can be built more quickly and more accurately when developers follow the guideline, “Do not code what you do not know how to test!”
To Learn More
The following are popular tools to help implement and facilitate TDD:
· JUnit Web site. http://www.junit.org.
· NUnit Web site. http://www.nunit.org.
· Framework for Integrated Test (FIT) Web site. http://fit.c2.com.
Model-Driven Development (MDD)
MDD finds its roots in the Object Management Group (OMG) Model-Driven Architecture (MDA). MDA is an approach to system specification and interoperability based on the use of formal models. MDD aims to facilitate the automatic construction of a software solution from a high-level domain-specific specification.
In MDA, platform-independent models (PIMs) are initially expressed in a platform-independent modeling language, such as the Unified Modeling Language (UML). The platform-independent model is then translated to a platform-specific model (PSM) by mapping the PIM to some implementation language or platform (Java or C#) using formal rules.
Model-Driven Development (MDD) is a style of software development where the primary software artifacts are models from which code and other artifacts are generated according to best practices. A model describes a system from a particular perspective. Models omit details that are not relevant so the characteristics of interest are seen more clearly.
Typically, software models are expressed in UML or with a domain-specific language (DSL) in products such as Rational Software Architect and Visual Studio Team System. Models hide technical implementation details so a system can be designed using concepts from the application domain. These expressions are meta-models that specify the application domain-modeling paradigm, including key concepts, relationships, constraints, and the rules governing code generation. They are represented either textually or visually within a domain model. Thus, they can be interpreted by humans, promoting communication about the intent of the software application, and processed by tools to facilitate the automated generation of the application.
In the process of developing an MDD solution, three main architectural aspects must be defined for the functional requirements. These are the solutions:
· Boundaries. Before creating any artifacts (code or otherwise), the solutions architect must understand the intent of the solution and where that solution fits in the context of the business problem that it is solving. The architect should also understand the basic flow of the business transactions, as if the transactions were being performed manually. Understanding the boundaries of the solution in this manner gives the architect a target to which they can design. It also allows the architect to communicate the scope of the solution and ensure that the architect envisions the solution as the stakeholders have defined it. It is a critical first step to defining the structure of the solution.
· Structure. The architect must first decide how the solution will be structured. One of the first artifacts is a diagram of the conceptual architecture. The conceptual architecture defines how the functional requirements will be fulfilled within the structure that is defined for the solution. The definition of the conceptual architecture should include: how the solution is exposed to external processes, how users will interact with the solution, how transactions will be maintained throughout the solution, how the solution's domain will be accessed and manipulated, and how the solution will handle events internally and externally.
· Domain model. Taking the conceptual architecture to the point where the solution can be developed with an extendible and maintainable result requires the solution's domain to be defined in detail. The domain model contains objects that are essential to the fulfillment of the solution's functional requirements. The model also defines relationships between objects.
MDD is gaining popularity now that tools are emerging to map the conceptual ideas directly to object definition and code generation, thereby reducing costs and promoting reusability of models.
MDD is a specific example of abstraction. In the book Software Factories, abstraction is defined as “a process that selectively removes some information from a description to focus on the information that remains.” The opposite of abstraction is refinement, which Software Factories defines as “making a description more complex by adding information.” Solutions architects work with developers to create abstractions and apply progressive refinements until the solution’s executables are produced.
UML creates a set of thirteen standard object models. These include models that describe a system from the user’s point of view (use case diagrams), from the standpoint of system structure (class diagrams), and from the standpoint of system behavior (activity diagrams, state diagrams). A solutions architect knows how to use a number of modeling tools, and can select the appropriate subset of these tools that make the most sense for his or her solution.
Consider for Yourself
· How would a model definition be affected by having a strategy map or strategy canvas?
· Do any of the methodologies lean to use of TDD or MDD more than any other?
Design patterns provide a roadmap and set of proven solutions to many problem spaces.
Design patterns provide a shared design vocabulary. They can reduce code and complexity, and can facilitate communication during design. Just as during a code walkthrough, where use of data structures, such as arrays and lists, are quickly understood, design sessions can be more effective when the parties have a shared vocabulary around design patterns. A team may want to create its own design catalog of agreed upon design patterns.
The visibility and wide adoption of software design patterns gained popularity with the 1994 publication of Design Patterns: Elements of Reusable Object-Oriented Software. While the authors, referred to as “The Gang of Four,” did not invent patterns, they identified patterns that already existed in the software community, patterns that reflected high-quality designs for specific problems. Their book served the following purposes:
· It introduced the idea and terminology of patterns to software design.
· It introduced a structure in which to catalog and describe design patterns.
· It cataloged 23 such patterns.
· It postulated object-oriented strategies and approaches based on these design patterns.
While individual pattern repositories and sources differ, they generally present patterns with the following elements:
· Name. All patterns are identified by a unique name.
· Intent or context. The purpose of each pattern is identified.
· Problem. The problem that each pattern is trying to solve is defined.
· Solution and variations. The way each pattern solves the problem is described in the context and any variants of the problem.
· Participants and collaborators. The entities involved in each pattern are identified.
· Consequences or forces. The forces at play in each pattern are investigated.
· Implementation. The ways each pattern can be implemented are described.
· Generic structure. A diagram (often UML) showing a typical structure for each pattern is provided.
Figure 3-11 is an example of a design pattern that Microsoft implemented in its IssueVision reference application:
Figure 3-11. IssueVision Observer design pattern
The specific problem that IssueVision’s solution architect needed to solve was that information could be changed in one Web part in a portal application that might also require updates to one or more other Web parts. The solution architect recognized this as a specific example of the general problem that changes in the state of one object may require changes to an unknown number of other objects. When the solution architect designs the classes to meet this requirement, he or she might be tempted to create a tightly coupled relationship between the “subject” object and “observer” object(s). As the number of these objects grow, the complexity of the code increases. This is shown on the left side of Figure 3-11. A solutions architect who is already familiar with the Observer design pattern is likely to quickly adopt a more elegant solution that requires introducing a data object as well. (More formally, there is a ConcreteSubject object and a ConcreteObserver object). This allows the more loosely coupled design shown on the right side of Figure 3-11. Note that this design scales up better as new subjects and observers are added. A solutions architect that has working knowledge of a catalog of design patterns is more likely to design better solutions than one whose design knowledge is limited to his or her own design experience.
For More Information
· Study the following common patterns used in industry:
To Learn More
· Beck, Kent. Test Driven Development: By Example. Addison-Wesley Professional. 2002.
· Brian Marick’s Testing Foundations Web site. http://www.testing.com.
· Newkirk, James W. and Alexei A. Vorontsov. Test-Driven Development in Microsoft .NET. Microsoft Press. 2004.
· Interview with Kent Beck on “Developer Testing.” ITConversations Web site. http://www.itconversations.com/shows/detail301.html.
· Rosenberg, Doug and Kendall Scott. Use Case Driven Modeling with UML: A Practical Approach. Addison-Wesley Professional. 1999.
· Cockburn, Alistair. Writing Effective Use Cases. Addison-Wesley Professional. 2000.
· Greenfield, Jack, Keith Short, Steve Cook, and Stuart Kent. Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. Wiley. 2004.
· Fowler, Martin, Kent Beck, John Brant, William Opdyke, and Don Roberts. Refactoring: Improving the Design of Existing Code. Addison-Wesley Professional. 1999.
· Object Management Group. "Model Driven Architecture." White Paper. ftp://ftp.omg.org/pub/docs/omg/00-11-05.pdf.
· Mellor, Stephen J., Kendall Scott, Axel Uhl, and Dirk Weise. MDA Distilled: Principles of Model-Driven Architecture. Addison-Wesley Professional. 2004.
· Yusuf, Larry, Mandy Chessell, and Dr. Tracy Gardner. “Implement Model-Driven Development to Increase the Business Value of Your IT System.” White paper. http://www-128.ibm.com/developerworks/library/ar-mdd1.
· Entwisle, Susan and Steve Eadie. “Model-Driven Development of .NET Enterprise Applications.” White Paper. http://msdn2.microsoft.com/en-us/library/aa730848(vs.80).aspx.
· Hofstader, Joseph. “Model-Driven Development.” White Paper. http://msdn2.microsoft.com/en-us/architecture/aa964145.aspx.
· Gamma, Erich, Ralph Johnson, Richard Helm, and John M. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional. 1995.
· Alexander, Christopher. The Timeless Way of Building. Oxford University Press. 1979.
· Alexander, Christopher. A Pattern Language: Towns, Buildings, Construction. Oxford University Press. 1977.
· Krebs, Jochen. “Patterns in Action.” White Paper. http://www-128.ibm.com/developerworks/rational/library/may06/krebs.
· Shalloway, Alan and James R. Trott. Design Patterns Explained A New Perspective on Object-Oriented Design (Second Edition). Addison-Wesley Professional. 2004.
· Trowbridge, David, Dave Mancini, Dave Quick, Gregor Hohpe, James Newkirk, and David Lavigne. Enterprise Solution Patterns Using Microsoft .NET. http://msdn2.microsoft.com/en-us/library/ms998469.aspx.
· Freeman, Elisabeth, Eric Freeman, Bert Bates, and Kathy Sierra, Head First Design Patterns. O’Reilly Media, Inc. 2004.
· Microsoft patterns & practices Development Center Web site. http://msdn2.microsoft.com/en-us/practices/default.aspx.
Lesson Wrap Up
A solutions architect who understands different methodologies and frameworks, Test-Driven Development, Model-Driven Development, and design patterns is able to architect solutions that are more complex and more adaptable than solutions architected by people without this knowledge.
This lesson focuses on elements related to strengthening skills in both the communications and organizational dynamics competencies in that solutions architects must communicate needs as well as deployment and operations standards to infrastructure architects to build effective relationships with other architects and project stakeholders.
Topic 1: Overview of Deployment and Infrastructure Impact
In this topic, we will discuss how the solution architect’s decisions impact deployment. We will also describe how early and frequent interaction between the solution architect and infrastructure architect is a critical success factor for successful solution deployment.
Deployment considerations should begin when the solutions and infrastructure architects are introduced to the solution’s problem space during the business plan development (see Figure 1-1). During requirements gathering and design, the solutions and infrastructure architects identify the solution infrastructure for production and deployment.
Figure 4-1 shows how the solutions architect and the infrastructure architect should be working from an agreed-upon deployment process. This process is often constrained by deployment guidance that may be specific to the platform, industry, and/or organization’s practices. The solution’s platform-specific deployment guidance is often the first source of guidance.
Figure 4-1. Solution deployment is dependent on industry, platform, and organizational guidance
Common Deployment Errors Introduced During Development
In the total solution life cycle, the development and test iterations step is the most influential from an overall deployment perspective. It is critical that the infrastructure architect actively participates during this step. In practice, this is often not the case, either because the infrastructure architect’s time is thinly spread across multiple projects or because the solution architect and infrastructure architect may report up into separate silo organizations.
Even when there is adoption and effective execution of frameworks, methodologies, and development models, there are often decisions made that severely hinder effective deployment. Different development methodologies and development models also lead to different deployment models. The following is a list of frequent deployment errors, with associated best practices for mitigation:
· Dissimilar development, test, and production environments. Caused by solutions built and debugged only at the development platform level. Building these environments as similar as possible realizes environmental, configuration, and security constraints earlier in the development life cycle. Especially with virtualization, there is now much less time and expense needed to build environments with identical characteristics.
· Solutions developed as administrator/super user. Too often, developers choose the easy path of building solutions with full privileges in the development environment, which means that design problems may not become apparent until deployment. This creates the worst scenario for successful deployment. The solutions and infrastructure architects should work together to create a set of security identities and constraints that are identical across each environment (development, testing, and deployment). In practice, it is often the case that the business requirements for a “security matrix” that shows which groups of users have access to which solution features are completed late. It is important that the security matrix be completed early, so that it can be incorporated into the test cases.
· System environment changes during development. During development, there may be changes to the production environment that are not replicated in the development environment. Or a developer may make a change in the development environment that cannot be performed in the production environment. One early warning sign is when more than one or two people are able to make server configuration changes in the production environment. This can manifest itself during a post-deployment problem resolution process when developers state, “But it’s working in my environment.” In some organizations, there is little forward progress in solution development, because most developer time is spent resolving issues in the production environment. It is the job of the solutions architect to communicate with the infrastructure architect so that unplanned changes do not happen.
· Development short cuts and quick fixes. These give the illusion of accelerating the development life cycle, but they almost always cost more when deployment occurs. The following are some examples:
· When developing and running processes as a non-administrator (good best practice), writing to the system registry, event, or error systems ceases to work, so a quick-fix is to write errors to a text file instead. This results in operations monitoring systems such as Microsoft Operations Manager (MOM) and HP OpenView not being informed of issues when they are logged. It is better to find the proper procedures to allow a non-administrator to access the required system resources. The infrastructure architect may be able to assist here.
· Avoiding the creation of strongly named keys for DLLs in a .NET solution may be easier and work when the binaries are in the same directory, but they will fail when they are deployed to the global assembly cache (GAC). It is better to learn necessary procedures earlier in the development life cycle than later.
· Problems as basic as hard-coded resource locations and hard-coded security information persist in many software development organizations.
· Responsibility and victims. This occurs when one party must wait for another to respond. In manufacturing, a lean manufacturing facility allows a worker to stop the entire production line when an issue is discovered and must be resolved. The matter is immediately escalated to the appropriate management levels. Doing the same with software development prevents one group from being the victim of another group’s lack of responsibility. The co-location of resources advocated in extreme programming and the ensuing peer accountability are an example of a mitigation strategy built into a methodology. After an escalation is raised, visibility of the issue and any associated delays can bubble up to higher levels of the team as time moves forward without progress. Early, proactive consensus around expectations by all parties is an effective mitigation strategy. It may even be effective to create service-level agreements similar to those that exist with end-user organizations.
Many deployment references offer guidance based on experience from what has failed in prior poor deployments. Lessons learned are always a good source of guidance, but they are too often forgotten by teams resulting in no significant changes to future deployment behaviors. One approach to enforce repeatable deployment success is to implement and refine deployment plans generated as part of the chosen development methodology.
One such deployment plan offering a strong mitigation strategy that helps address each of the above deployment errors is trial deployments. Trial deployments force allocating the time for constructive, early interactions between the solutions architect and the infrastructure architect. A solutions architect who insists on early practice deployments often uncovers problems earlier, saving time and money on the schedule. Trial deployments are especially important when the solutions team members and infrastructure team members do not have a lot of shared experience in deploying applications.
Exercises for Understanding
· What is the cost (in hours) of dissimilar development, test, and production environments? Calculate this cost for a past project based on the total labor hours spent resolving deployment issues of this nature.
· How can test plans in a solution’s development methodology affect deployment?
Software Deployment Method
While many exist, the IBM Redbook, “The Software Deployment Mystery – Solved” offers a software deployment method that seeks to maximize deployment success. The following is an overview of this example method.
The Software Deployment Method consists of three phases and eleven steps:
Phase 0: Prepare for deployment
Here, you build the ground work for a successful deployment.
0. Create the software deployment team (SDT). Determine the team that will be focused on the overall success of the software deployment.
· Review the critical deployment documents (contract, roles and responsibilities, business context diagram, requirements, solution concepts, and so forth). Obtain a common understanding of the critical documents that will be used in the deployment process.
· Develop a high-level deployment plan. Create a high-level mapping of products to your projects and assign ownership at a project level.
· Establish a deployment partnership. A formal meeting between deployment owners and participants to come to closure on major issues that must be addressed.
Phase 1: Refine and promote the plan
After an agreement is in place, critical inputs are reviewed to inspect any changes made during final negotiations; the deployment plan is refined; and the deployment kickoff meeting is held.
· Refine the high-level deployment plan. Revise the solution architecture and deployment plans to reflect any changes made during the final negotiations.
· Finalize the deployment plan. Obtain final agreement with the deployment plan.
· Conduct deployment kickoff meetings. Market and communicate the deployment plan and overall vision to all current and potential users within the organization.
Phase 2: Deploy software
Begin executing against the deployment plan, starting with the carefully selected quick deployment wins and then moving on to the other projects.
· Achieve quick deployment wins. Implement the quick deployment wins and, in doing so, demonstrate success.
· Execute the deployment plan. Build on the success and momentum of the quick deployment wins.
· Identify new business needs. Because of the dynamic nature of business, business needs that were not known or identified during Phases 0 and 1 typically arise after deployment has begun. These new business needs may be satisfied with software that was part of the original agreement, or they may require additional software that will be deployed in new projects. This is referred to as “the software gap.” To prepare for and meet the new business needs, the SDT should return to Phase 0 and follow the roadmap for its planning and implementation
· Update the business plan. Complete any purchase/development of software and potentially additional services and education that will meet the new business needs identified in step 9.
A graphical representation of the IBM Software Deployment Method can be found at http://www.redbooks.ibm.com/redbooks/SG246070/wwhelp/wwhimpl/js/html/wwhelp.htm, Figure 1.4.4
IBM’s Software Deployment Method is a continuous process. The outer circle represents the activities that should occur before the software deployment. The inner circle represents the necessary steps to ensure that software is deployed properly. After a new software requirement is defined, steps 0 through 3 should occur in sequence (outer circle). After the purchase of software is completed, the life cycle enters what is called the “software deployment mill.” In the mill, steps 6 through 10 are executed (inner circle).
Consider for Yourself
At what point in the total solution life cycle does a solutions architect inform business stakeholders about potential added expense because of the software gap identified in Phase 2: step 9?
To Learn More
· Bierds, Bill, Jeremy Gibson, David Blackman, Mike Ransom, Reid Byers, Charles P. Brown, Sandor Hasznos, Carolyn Hungate, Calvin Lawrence, and Fernando Zullani. “The Software Deployment Mystery – Solved.” White Paper. http://publib-b.boulder.ibm.com/abstracts/sg246070.html. 2004.
Topic 2: Operations and Infrastructure Frameworks
· This topic will focus on elements related to strengthening skills in the strategy competency in that solutions architects must understand how operational frameworks impact their solution
Solutions and infrastructure architects should have an appreciation for the close relationship they hold. Both need exposure and awareness of the others’ frameworks and methodologies. In this topic, we will introduce several infrastructure operational frameworks and identify how certain choices during development can accommodate operations.
The Information Technology Infrastructure Library
The Information Technology Infrastructure Library (ITIL) is a set of operational procedures that define organizational structure and skill requirements for the IT organization; it also includes a set of standard operational management procedures to allow the organization to manage an IT operation and associated IT infrastructure. The operational procedures are supplier-independent and apply to all items of equipment within the IT Infrastructure.
The library comprises seven distinct sets:
· Service support. This set focuses on the user of the organization’s information and communications technology (ICT) services and is primarily concerned with ensuring that they have access to the appropriate services to support the business functions.
· Service delivery. This set focuses on the business as the customer of the ICT services.
· ICT infrastructure management. This set focuses on the processes, organization, and tools needed to provide a stable IT and communications infrastructure covering network service management, operations management, management of local processors, computer installation, and acceptance and systems management.
· Planning to implement service management. This set focuses on guidance and alignment of the business needs to IT to assess if IT service provisioning meets the requirements of the business.
· Applications management. This set focuses on how applications can be managed from a service management perspective by providing an outline of the application management life cycle and guiding how applications can be managed from a service management perspective.
· The business perspective. This set focuses on embracing business relationship management, exploitation of information, communication, technology, and partnerships and outsourcing to help business managers better understand IT service provisioning.
· Security management. This set focuses on preventing the occurrence of security-related incidents by managing the confidentiality, integrity, and availability of IT services and data with business requirements at an acceptable cost.
Within these sets are the specific descriptions and definitions of the various ITIL disciplines. We will examine the two most commonly used sets (the core sets): service support and service delivery.
· Incident management. Restore normal state IT service operations as quickly as possible to minimize the adverse impact on business operations. Basically, incident management is the way the service desk puts out daily fires. An incident is any event that is not part of the standard operation of the service. It is something that causes an interruption or a reduction of the quality of the service. Incidents usually come from users, but they can have other sources, such as operations monitoring and detection systems. The outputs of the process are requests for changes (RFC), resolved and closed incidents, management information, and communication to the customer.
· Problem management. Minimize the adverse impacts on the business of incidents and problems caused by errors in the IT infrastructure and initiate actions to prevent recurrence of incidents related to those errors. Where incident management is concerned with restoring service as quickly as possible, problem management is concerned with determining and eliminating the root cause and hence eliminating repeated problems. A problem is the unknown cause of one or more incidents, often identified as a result of multiple similar incidents. A known error is an identified root cause of a problem. The outputs of incident management are consumed by problem management to form a plan of attack for the next occurrence of a problem.
· Configuration management. Identify, record, and report on configuration items and their relationships that underpin IT services. This allows IT to provide information about the IT infrastructure and related processes to IT management and enable control of the infrastructure by monitoring and maintaining information on all the resources needed to deliver services.
· Change management. Coordinate and control all changes to IT services to minimize adverse impacts of those changes to business operations and the users of IT services. This allows IT to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes to minimize the impact of change-related incidents upon service quality and consequently to improve the day-to-day operations of the organization.
· Release management. Implement changes to IT services taking a holistic (people, process, technology) view that considers all aspects of a change, including planning, designing, building, testing, training, communications, and deployment activities. The practice of effective software control and distribution (SC&D) involves the creation of a definitive software library (DSL), into which the master copies of all software are stored and from which control and release of these software assets is managed. SC&D procedures include the management of software configuration items and their distribution and implementation into a production environment. This involves the definition of a release program suitable for the organization, the definition of how version control will be implemented, and the procedures surrounding how software will be built, released, and audited.
· Service level management (SLM). Plan, coordinate, negotiate, report on, and manage the quality of IT services at acceptable cost. The goal is to maintain and improve on service quality through a constant cycle of agreeing, monitoring, reporting, and improving the current levels of service. SLM focuses on the business, and maintains alignment between the business and IT.
· Financial management for IT services. Give accurate and cost-effective stewardship of IT assets and resources used in providing IT services. Financial management for IT services is used to plan, control, and recover costs expended in providing the IT service negotiated and agreed to in the service level agreement (SLA).
· Capacity management. Ensure that all current and future capacity and performance aspects of the IT infrastructure are provided to meet business requirements at acceptable cost. This involves input from many areas of the business to identify what services are (or will be) required, what IT infrastructure is required to support these services, and the cost for this infrastructure.
· Availability management. Optimize the capability of the IT infrastructure, services, and supporting organization to deliver a cost-effective and sustained level of service availability that meets business requirements. Availability is usually calculated based on a model involving the availability ratio (the ratio of the amount of time a system is actually available for use compared to the amount of time it is supposed to be available) and techniques such as fault tree analysis (diagram of cause-and-effect relationships, showing the possible outcomes if a particular course of action is taken or continued).
· IT service continuity management. Support business continuity management functions by ensuring that IT services can be recovered in the event of a major business disruption within required timeframes. This is the process by which plans are put in place and managed to ensure that IT services can recover and continue should a serious incident occur. It involves proactive measures to reduce the risk of a disaster in the first instance.
As ITIL grows in international popularity, many unauthorized books, Web sites, and unaccredited organizations have surfaced. All authorized documents for ITIL are managed through the official publications from the United Kingdom’s Office at Government Commerce (OGC).
Exercises for Understanding
· For each description in the ITIL Service Support and Service Delivery sets, identify where in the total solution life cycle a solutions architect should interact with the infrastructure architect to establish common goals for optimal operation of the solution.
To Learn More
· OGC - IT Infrastructure Library (ITIL) Web site. http://www.itil.co.uk.
· Official OGC ITIL publications Web site. .
· Riley, Alison, Joel Pomales Palmer, Jose Samuel, Dawn Cleaver, John Jasinski, Randy Steinberg, Peter Brooks, and Javier Arcal. “The ITIL Open Guide.” Web site community. .
Microsoft Operations Framework
Microsoft Operations Framework (MOF) provides operational guidance that enables organizations to achieve mission-critical system reliability, availability, supportability, and manageability of its products and technologies. With MOF guidance, you will be able to assess your current IT service management maturity, prioritize your processes of greatest concern, and apply proven principles and best practices to optimize server platform management.
Figure 4-3. The MOF life cycle
MOF simplifies IT processes by dividing IT services into four quadrants:
· Optimizing quadrant
· Changing quadrant
· Supporting quadrant
· Operating quadrant
The next sections describe each of these quadrants.
This quadrant encompasses processes and IT functions dedicated to planning and implementing enhancements to the IT environment through a continuous cycle of process improvement. Service management functions (SMF) in the optimizing quadrant assure tighter alignment of operations with business needs and long-term business strategies reflected as changes in the IT infrastructure and instituted through the change management process. This quadrant has eight sets of SMFs:
· Availability management. This set of practices describes processes and best practices to ensure that services achieve their service level agreements (SLA) for availability.
· Capacity management. This set of practices works to optimize capacity and improve system performance through planning, sizing, and controlling network resources as efficiently as possible.
· Financial management. This set of practices defines IT service budgeting processes and provides guidance for service charge-backs, accounting, and decommissioning.
· Infrastructure engineering. This set of practices provides guidance for collecting, creating, and managing standards and policies for IT services and infrastructure.
· IT service continuity management. This set of practices provides best practices and guidance to support business continuity through the implementation of effective IT service recovery procedures.
· Security management. This set of practices defines and communicates the IT organization’s security plans, policies, guidelines, and the relevant regulations that mandate them. It works in concert with security administration, which implements these policies, to secure corporate information and assets by controlling access, confidentiality, and authorization.
· Service level management. This set of practices provides a structured process for business users and IT service providers to discuss the service levels needed and assess their current performance.
· Workforce management. This set of practices focuses on the recruitment, training, readiness, compensation, and retention of the skilled IT personnel in the IT organization.
This quadrant describes processes, responsibilities, reviews, and best practices that help organizations manage changes to their IT infrastructure. Through classification of change types, the appropriate assignment of authorization responsibilities, and a consistent change management and release process, organizations following MOF best practices reduce incompatible or conflicting changes and streamline their release efforts. This quadrant has three sets of SMFs:
· Change management. This set of practices describes a consistent set of processes to initiate infrastructure changes, assess and document their potential impacts, approve their implementation, and schedule and review their deployment.
· Configuration management. This set of practices provides the foundation for decision making in the Changing quadrant, negotiating SLAs, assessing IT capacity, and other critical processes.
· Release management. This set of practices coordinates efforts to deploy services and applications into a managed environment.
This quadrant contains those processes and practices that are required to fully support the activities and processes that are performed to resolve user and system-generated queries, issues, or problems. This quadrant has three sets of SMFs:
· Incident management. This set of practices provides organizations with the ability to first detect incidents and then to target the correct support resources to resolve the incidents as quickly as possible.
· Problem management. This set of practices is implemented at the same time as incident management processes so organizations can identify and resolve the root causes of any significant or recurring incidents, thus reducing the likelihood of recurrence.
· Service desk. This set of practices is the first point of contact for the company; it focuses on efficient and effective response to customers’ problems and concerns.
This quadrant encompasses the collection of processes and IT functions dedicated to the ongoing maintenance, monitoring, control, and protection of IT infrastructure assets. This lets the IT organization move beyond simple infrastructure maintenance, such as patch management or backup-and-restore. The IT organization can focus on proactive measures that improve reliability and performance. This quadrant has seven sets of SMFs:
· Directory services administration. This set of practices provides processes and best practices for the routine management of the directory systems used to locate users, files, services, and servers.
· Job scheduling. This set of practices handle the sequencing of various batch jobs and other workloads (printing, database, backups, and others) for optimal use of network resources.
· Network administration. This set of practices defines and delivers the processes and procedures required to operate basic network services on a day-to-day basis, including Dynamic Host Configuration Protocol, Windows Internet Name Service, and Domain Name System.
· Security administration. This set of practices deals with the daily, routine application of security policies and best practices to maintain a secure operating environment.
· Service monitoring and control. This set of practices provides best practices for making rational decisions for maintenance, optimization, risk mitigation, and proposed changes for monitoring and resolving incidents and alerts in the production environment.
· Storage management. This set of practices is dedicated to safe, secure storage of data, effective backup-and-restore policies, and efficient use of storage resources to optimize the business’s investment in physical storage components.
· System administration. This set of practices is responsible for managing a variety of services, with varying levels of control. These include crucial services, such as messaging, databases, operating systems, Internet, and telecommunications.
The four quadrants are part of the Process Model element of MOF. The other element in MOF is the Team Model. The Team Model organizes the activities of IT operations into seven distinct role clusters that represent areas, or functional roles, within IT operations where particular staff members or groups are performing activities toward a shared goal or a similar mission of service.
Exercises for Understanding
· Compare and contrast how SMFs are affected when a solution is thick client/server- based versus thin client/browser-based. Could this affect a solutions architect’s design decisions?
To Learn More
· Microsoft Operations Framework (MOF) page on the Microsoft TechNet Web site. http://www.microsoft.com/technet/solutionaccelerators/cits/mo/mof/default.mspx.
Solutions Development Impact on Operations
The following common solutions development design considerations and decisions affect overall operations from deployment to maintenance:
· Solution dependency requirements. The requirement for certain configuration settings (cookies, group policy settings, RAM, processor requirements, and others), required version numbers for the required runtime libraries (.NET Framework, Java Runtime Environment, Adobe Flash Player, and so on) not only affect deployment plans; they also affect how an infrastructure architect builds systems to be distributed throughout the organization.
· System performance and health monitoring. As identified in the operations and infrastructure frameworks explained earlier, system performance and health are closely monitored. A solutions architect should address the following factors related to the solution’s ability to monitor its overall operational health:
· Does the solution log to an operations-friendly repository? Most infrastructures use some form of automated operations monitoring such as HP OpenView or Microsoft Operations Monitor (MOM). These products can effectively monitor system event logs to trigger appropriate operations response to solution-raised events.
· Does the solution log more than exceptions? Most solutions log system exceptions by means of the run-time framework in which they are built. These usually mean some portion of the solution or system is non-functional. A better dynamic is to build in operational thresholds that trigger events showing concern in addition to crisis. For example, a data access component can monitor response to its database query and report a concern when the response time exceeds a set threshold.
· Does the solution maintain the end user session details needed by the help desk worker? When helping an end user resolve a problem, the help desk worker often begins by asking the end user to identify the steps performed to get to the point in the application where the problem occurred. This process is both time-consuming and error-prone, because the end user may not be able to accurately describe the steps performed. A solution architected to provide access to these user interaction steps provides for faster and less-expensive problem resolution.
· System interaction independence. At any moment, operations may need to move a solution from one server to another with a different disk and IP address configuration. Solutions should never hard-code or assume certain components will always be available or at a hard-coded location or address. Generally, these issues are found during deployment from development to test or from test to production, but the worst time to discover them is after production is in full operation.
· Maintenance-friendly solutions. Most solutions require maintenance at some level. Solutions that are maintenance-aware can provide either limited functionality (for example, read-only access to data) or redirect to an informative explanation (for example, during the rebuilding of OLAP cubes) during a maintenance cycle. It is also desirable to be able to query a solution for activity metrics such as the number of active users, transactions, or average throughput of work components. The solutions architect may need to design this query capability into the application, or it may be provided by the development environment (such as the Microsoft SQL Server SQL Profiler tool). A solutions architect uses these activity measurements to make ongoing design decisions about scalability and performance.
Solutions architects that understand their organization’s operations and infrastructure frameworks can make architectural decisions that prevent operational problems and enhance operational efficiency. This increases the solution’s value to the organization.
Exercises for Understanding
· Talk to an infrastructure architect and identify the steps and processes he or she performs when a solution ceases to function in production. How might that solution better inform operations of its failures?
Topic 3: Valuation of a Solution
This topic identifies activity generally after a solutions architect’s engagement. However, it will serve to provide background and understanding to strengthen communication and organizational dynamics skills with regard to executive management. For a discussion of related material on return on investment (ROI), payback period, and total cost of ownership (TCO) calculations, see Module 1, Lesson 2, Topic 4.
A solutions architect determines how a solution’s success will be measured during the Business Planning step of the total solution life cycle. The resulting metrics may, in turn, roll up into the IT organization’s metrics, which might be described as project portfolio metrics or IT payoff metrics.
The question of how best to measure the value realized from investment in a technology solution is controversial and evolving. In the development world, delivering on or before the release date may signify successful completion and is sometimes accompanied with elaborate celebrations. “On time and on budget” is viewed as sufficient success criteria by more than one development organization.
This is unfortunate because no one else in the organization may share that view. The end users will have to adopt the solution and sustain its use before they realize value. The support system (help desk) will base their value judgment on the level of support required for the solution. However, the solution’s real value will be assessed by the executive management team who originally funded the investment.
The organization’s leadership team may also have different methods of assessing a solution’s value. This topic will discuss valuation from a variety of perspectives.
Value Measured by the CFO
The chief financial officer (CFO) may determine value from one or more of the following financial measurements:
· Return on investment (ROI). This measurement is used to evaluate the efficiency of an investment or to compare the efficiency of a number of different investments.
· Payback period. This measurement provides the length of time required to recover the cost of an investment.
· Internal rate of return (IRR) or economic rate of return (ERR). This measurement provides the discount rate used in capital budgeting that makes the net present value (NPV) of all cash flows from a particular project equal to zero. Generally speaking, the higher a project's internal rate of return, the more value it posses.
· Discounted cash flow (DCF). This measurement is used to estimate the attractiveness of an investment opportunity. DCF analysis uses future free cash flow (CF) projections and discount rate (r) (most often using the weighted average cost of capital) to arrive at a present value, which is used to evaluate the potential for investment. If the value arrived at through DCF analysis is higher than the current cost of the investment, the project is considered to be of value.
+ … +
Figure 4-4. Calculating discounted cash flow
· Economic value added (EVA). This measurement is used to measure a solution’s financial performance based on the residual wealth calculated by deducting cost of capital from its operating profit.
EVA =Net Operating Profit - (Capital * Cost of Capital)
Figure 4-5. Calculating the economic value added
Value Measured by the CIO
The chief information officer (CIO) perspective may determine value from one or more of the following financial and non-financial perspectives:
· Solution is on time and within budget
· Decreased costs
· Increase in productivity
· Increased profits/revenue
· Added flexibility/scalability
· Total cost of ownership (TCO)
· Payback period
· Reduced headcount
· Return on investment (ROI)
Approaches to Determining Value
Research into the value of IT solutions identifies two approaches:
· Variance approach. This approach measures the relationship between IT investments and organizational performance in terms of higher revenues, lower costs, improved market share, and so on. This approach focuses on the what question. What is the relationship between IT investments and organizational performance? Advocates of the variance approach argue that it reveals statistically proven effects of IT. However, several studies suggest that the relationship between IT investments and organizational performance cannot be proven—this has become known as the “IT productivity paradox.”
· Process approach. This approach focuses more on the how question. How do IT investments improve organizational performance? Soh and Markus synthesized the different models of the process approach into a comprehensive framework for the IT value creation process. For a graphical representation of this process, see Soh and Markus’s 1995 paper, “How IT Creates Business Value: A Process Theory Synthesis,” Proceedings of the Sixteenth International Conference on Information Systems.
The relationship between IT expenditures and IT assets is explored to identify IT efficiency. Next, the relationship between IT impact and organizational performance is explored to identify IT alignment.
One of the core concepts of the process approach is the time dimension for IT value. Most technologies have a life cycle where value dissipates over time. Using available technologies as optimally as possible and switching to new technologies at the right moment are the key to gaining the most from a TCO perspective.
Real Options Valuation
The traditional CFO and CIO value calculation methods are limited in their ability to cope with risk and managerial flexibility. Generally, management adapts plans based on actual conditions; this flexibility is not adequately valued in any of the valuation methods mentioned earlier.
The real options valuation (ROV) theory calculates a flexibility value on top of the net present value (NPV) of a project. This flexibility value reflects the ability to alter the investment outlay and the timing of outlays based on changes in the competitive environment. ROV treats the possibilities of adapting the investment plan as real options. The opportunity to invest can be seen as a call option, involving the right to acquire an asset for a specified price (investment outlay) at a future moment. A call option gives the holder the right, for a specified price within a given amount of time, to exercise the option to acquire the underlying asset. The techniques, derived from option pricing, quantify the management’s ability to adapt its future plans to capitalize on favorable investment opportunities or to respond to undesirable developments in a dynamic environment by cutting losses.
Because a solutions architect understands that a better-architected solution is able to better anticipate future requirements changes, the ROV model arguably best reflects the higher relative value of more flexible software. A solutions architect who calculates the ROV across alternative designs can help deliver better ROV in the solution.
Valuation Models Inform Only the Decision-Making Processes
Performing investment calculations is a typical part of the due diligence requirements that often come from the office of the CFO or CIO, but the value of a solution rarely, if ever, comes down to a set of calculations. As former General Electric CEO Jack Welch noted in a 2007 Business Week article about decision models for technology launches, “Nor will you ever be 100% certain about the viability of your technology. And forget discounted rate-of-return analyses. With a new technology, those numbers fall somewhere between guessing and wishful thinking. Which is why your decision ‘model’ comes down to two factors: a positive gut feeling drawn from enough data, and a person in your organization who’s wildly excited to lead the charge.”
Regardless of the actual decision-making practices in your organization, a solutions architect who can use tools to quantify his or her decisions is in a position to make better decisions overall.
Solutions Development Impact on Valuation
A solution should seek to actively report on hard savings generated by its use and to convert soft savings into hard savings whenever possible. This information offers management the accurate facts for their ongoing analysis of the solution and related systems.
Specifically, a solution’s valuation model may need to account for the changes that the solution brings about in some combination of the organization’s business processes and its talent development systems. For example, implementing a solution may allow an organization to double the amount of work that it processes with only a 20 percent increase in staff.
Consider for Yourself
· Review several past solutions and calculate the TCO. How does this relate to the payback period and ROI projected when the solution was developed?
To Learn More
· Investopedia Web site. http://www.investopedia.com.
· Soh, C. and Markus, M. “How IT Creates Business Value: A Process Theory Synthesis.” Proceedings of the Sixteenth International Conference on Information Systems. 1995.
· Alleman, James.”Real Options, Real Opportunities,” Optimize. January 2002, Issue 3. http://www.optimizemag.com/issue/003/financial.htm.
· Teach, Edward. “Will Real Options Take Root?” CFO Magazine. July 2003. http://www.cfo.com/article.cfm/3009782.
· Alster, Norm. “ROI: Results Often Immeasurable?” CFO Magazine. October 2002. http://www.cfo.com/article.cfm/3006818.
· Soetjipto, Alexander. “Capturing the Value of Flexibility in Information Technology Project Using Real Option Valuation.” White Paper. http://www.umsl.edu/~sauter/analysis/6840_f03_papers/soetjipto/6840Project.htm. 2003.
· Silvius, A.J. “Does ROI Matter? Insights into the True Business Value of IT.” The Electronic Journal Information Systems Evaluation. Volume 9, Issue 2. http://www.ejise.com/volume-9/v9-iss-2/v9-i2-art6.htm. 2006.
· Welch, Jack and Suzy Welch. “When to Talk, When to Balk.” Business Week. April 30, 2007, p. 102.
Lesson Wrap Up
A solutions architect who understands how the solution will be deployed and operate can make architectural decisions that reduce the associated deployment time and operational costs. A solutions architect who understands financial evaluation is able to design more valued solutions.
Sample Scenario: Soccer Stadium Season Tickets Resale System
A European soccer team’s ownership and executive management has been mining their extensive data around home game attendance and profits. From their research, they realized that on average, 20 percent of their season ticket holder seats were unused at any particular home game.
Executive Management Viewpoint
Season tickets are paid for at the beginning of the season, so there is no sales revenue loss if a season ticket holder does not attend.
However, they also realized that every filled seat generates, on average, €25 in concessions and novelty sales. If they could fill the empty season ticket holder seats, they could create additional revenue from parking, concessions, and licensing sales. They have developed a strategy where they will allow season ticket holders to resell tickets for games they cannot attend. Gaming regulators will allow the resale to occur only at face value of the ticket, no more, no less, and no service charges. The team’s owners would like to create a greater fan sense of community around this opportunity where team members will share personal anecdotal stories with fans to encourage non-season ticket holders to sense the prestige of being a season ticket holder for a day.
They want to create this sense of community by having season ticket holders register their tickets for resale (having the revenue credited to their account) and allowing fans to select and purchase available season tickets. Additionally, they want approved external ticket sales organizations and agencies to also broker available season tickets by allowing them to securely query into their systems to view available tickets and to make purchases on behalf of their patrons.
The team’s home schedule includes 12 regular games a season and their stadium seats 60,000 fans, 80 percent (48,000 seats) of which are season tickets. On average, 20 percent (9,600 seats) of the season-ticket seats are empty losing €240,000 in concessions revenue per game, or approximately €2.9M each season. However, they do not expect to fill every vacant season ticket seat, so actual revenue recouped will be less.
Exercises for Understanding
· Sketch a simple Norton and Kaplan strategy map depicting a strategy for the team’s investment of the “Season Ticket Holder for a Day” campaign.
Enterprise Architect and Business Analyst:
The enterprise architect for the team uses a slimmed down version of Zachman to get this system operational inside of the nine-months before the next season begins. The business analyst will work closely with the team’s marketing department to promote the new program where fans can become a “Season Ticket Holder for a Day.”
Solutions Architect Assignment:
Build a business plan to implement the soccer stadium season tickets resale strategy integrating into existing systems where possible.
The team has a Web presence with a self-made ASP.NET portal. Two ticket agencies want to integrate with the idea of reselling unused season tickets for games. One is Java-based and the other is ASP (not ASP.NET) based. The next sections describe the systems that have been identified.
The administrative system must allow season ticket holders to post individual tickets for games they do not plan to attend. This must supply the means to:
· Register the tickets as available for resale.
· After the tickets are sold, credit the season ticket holder’s account.
· Nullify season ticket holder’s ticket after those tickets are sold and new tickets are printed.
· Allow season ticket holders to view their account activity and either cash in their account or apply it toward next year’s purchase.
The community system must have an environment where fans can be made aware of season ticket resale opportunities. This includes providing the ability to:
· Promote the idea, share experiences with season ticket resale patrons; this can be facilitated through a blog-like interface.
· See real-time information about season tickets currently available, reserve the tickets, and purchase the tickets. The available seats should be displayed on a map of the stadium.
· Post requests to season ticket holders for desired games for which fans are seeking tickets.
The integration system must have an interface for secure external business to business access. This includes providing the ability to:
· Keep track of the inventory of available season tickets available for resale.
· Place a 20-minute hold on up to eight tickets being considered for purchase.
· Purchase and reprint resold tickets.
· Perform electronic funds transfer (EFT) transactions for appropriate accounts.
Cost Estimation and Justification:
What will this solution cost? Should it be built, purchased, or both? Which methodologies and models will you use? What means will be used to justify the investment? What is the rationale you will give executive management that they should proceed and approve the funds you request?