Shark introduction Morphology and its behaviour characteristics
Approach To It Strategy And Architecture
1. Approach to IT Strategy and Architecture Alan McSweeney
2. The Adaptive Enterprise Business and IT synchronised to capitalise on change Business Information Technology Business benefits: simplicity, agility, value
3.
4.
5.
6.
7.
8. Solution Architecture Bridges the Business and IT Gap Solution Architecture Business Problem IT Solution Business/IT Alignment
9. Architecture Scope Building architecture Information system architecture Discrete (project) Examples: e-procurement, email Initiative (program) Examples: CRM, KM Enterprise Example: extended value chain
25. IT Strategy and Architecture Framework Actions Actions implementation principles rationales implications obstacles Implementation view Business view Actions Technical view obstacles implications rationales technical principles functional principles rationales implications obstacles Functional view Actions Business drivers Goals business principles rationales implications obstacles
26.
Notas do Editor
That’s what the Adaptive Enterprise is all about: Business and IT synchronised to capitalise on change. By combining our own experience with the expertise of world-class partners and the industry’s strongest and broadest portfolio of products, services, and solutions, we’re building a powerful platform for managing change. The Adaptive Enterprise allows customers to capitalise on the opportunities change creates. The Adaptive Enterprise succeeds by delivering three major customer benefits: Simplicity, Agility, and Value.
Key Points: Agility is a critical business capability today because: Change is constant Everyday events that send ripples throughout the organisation, and the IT that supports it. Change is unexpected A merger, new market opportunity, sudden shift in competitive landscape, new partner. Change is disruptive The goal is to minimise the impact of disruptions with an IT environment that is synchronised with the business. Change presents opportunities The ability to adapt to change is a key advantage in business. To survive, compete and win, enterprises must adapt.
Key takeaway: “ It is not the strongest of the species that survives, not the most intelligent, but the one most responsive to change.” (Charles Darwin) Darwin Reference Architecture provides a means for: Brings standardisation to the entire IT environment Eliminates vertical islands Embraces heterogeneity and legacy IT environments Uses automation to scale and reduce complexity Virtualises all IT assets Helps convert fixed costs to variable costs Its components include: Business strategy - Influences and determines the dynamics upon which business and IT are synchronised Business processes - A series of actions, changes and functions extended and linked across a value chain to accomplish a business result Application services - Applications that act as services to manage information for multiple business processes Management & control - Capabilities to synchronise business and IT by managing and controlling information services to support business goals and policies Infrastructure services - Capabilities shared by multiple applications that provide basic IT environment functionality
We’ve outlined 4 design principles to design and deploy IT for maximum agility: Simplification, Standardisation, Modularity and Integration. You need to apply these principles consistently across your business processes, applications and infrastructure. In fact, this is where all the “heavy lifting” is going to be done. We expect customers will spend the next 3-5 years getting infrastructures built to handle change. What do you need to do? Simplification: A business can no longer have a United Nations of applications. You must be on a crusade to simplify. Go from 12 instances of ERP to two…eliminate customisation! Standardisation: Standardise on a single instance of a key enterprise application; adopt a well-defined enterprise architecture with sound governance principles; leverage tools for standard processes like IT Information Library (ITIL). Modularity: Design around building blocks like modular storage and virtual servers; these are easier to change; this also allows you to wrap your existing infrastructure and protect your investment; rapid step-wise approach to delivering return on IT; not rip and replace – extend and embrace. This also gives rapid, stepwise return on investment Integration: Integrate and manage business processes down into the raw hardware, from the fans in the servers back up to the service-oriented architecture. And then link those systems with customers and suppliers… From the 50,000 foot view it all boils down to a shift from “vertical stacks” where resources are housed in silos to a “horisontal infrastructure,” which creates a common foundation on which you can layer any application or process. When you get your IT infrastructure right, anything is possible, and change becomes an opportunity, not an obstacle
Establishes a rational basis for decision-making Makes the vision real in a timely fashion Manages complex environments that include systems, organisations, and competitive pressures Implements an affordable, quality solution using proven methodology Readily takes advantage of new technologies through effective modularisation and layering Equips solution architects to guide the definition, development, deployment, and evolution of complex information systems by: Understanding your business context and information needs – how this solution adds value to your business Confirming that the solution addresses your business problem Matching appropriate technology with your needs to define a complete, clearly scoped solution Maintaining the system’s conceptual integrity over time Verifying that the system, as built, meets its requirements Evolving the system to meet changing business needs and take advantage of new technologies Delivers value to you! Solution architecture is responsible not only for defining technology, but matching appropriate technology with client needs. The system, as built, must meet both the business and technical needs. Solution architecture defines a unifying concept that is the essence of the system and the reason we create it. All parties must fully understand this concept and keep it in mind while the system is being built and deployed. Otherwise, the resulting solution might not come together as intended. By identifying and agreeing on the business needs that the solution must address in the early stages, solution architecture helps ensure that the system meets these needs as it is built. A good architecture: Helps drive the acceptance of the final solution. Is robust enough to accept new technologies and new requirements without compromising the original integrity of the solution.
SD has spent a lot of time talking to CEOs and CIOs. Here’s what they’re telling us: They want to maximise the return on their investment. Second, they need to manage and mitigate risk. Third, they need to improve their IT performance. And fourth, they need more agility. The net is: They want to be able to handle and take advantage of change today to improve their competitiveness, lower costs, and serve their customers better — and build an IT environment and business processes that can easily accommodate tomorrow’s changes. These objectives translate into specific challenges for every CIO in every enterprise size company. What are they? They need to run their IT department as a service delivery business. They need to turn various silos in the company, such as Customer Relationship Management, Human Resources, and Enterprise Resource Planning into cross-company business intelligence. And they need to ensure the availability and performance of critical systems.
According to a recent Meta Group study, 58% of IT managers don’t see themselves as partners with their business counterparts.
It is possible to build a small house without an architect if you have detailed specifications and nothing major is changed from the standard design. However, if the house has unique specifications, traffic flows, and room layouts, you would want an architect to ensure that the custom design works and the interconnections (plumbing, electrical, structural) are in place. Compare this to a discrete information architecture project, such as eProcurement. If an IT project has many interconnections, a solution architect is usually needed. A large office building presents a bigger set of problems that require an architect because there are so many things to consider (floors, offices, and interconnections between them). You might also need to consider issues, such as security (entrances, windows), shared systems (heat, electrical), access to other buildings (sidewalks, covered walkways). Compare this to a company-wide initiative, such as customer relations management (CRM), where it is more likely that you would need an architect to help create the overall integrated structure of the system and to ensure the interoperation of the components. With city planning or urban renewal, there is a complexity and richness of interconnections that need to be considered (basic services, roads, utilities, zoning, lack of a global security mechanism, and more). Compare this to an enterprise IT architecture. As with urban redevelopment, rarely does a computer system today exist entirely on its own. Computers are embedded in a context and must integrate with what exists. The challenge with both urban redevelopment and enterprise architecture is to decide what to keep and what to replace, and how to integrate what you keep with the new plan.
Establishes a rational basis for decision making Makes your vision real in a timely fashion Ensures IT alignment with your business goals Identifies problems and risks early Structures complex environments that include systems, organisations, and competitive pressures Implements an affordable, quality solution using proven methodology Provides a means to facilitate communication across functions Ensures the solution meets critical needs of your key stakeholders Ensures that you are solving the right problem
Eventually, all services/offerings will have underlying SD methodologies.
A conceptual framework for representing IT architectures and strategies and an integrated, complementary set of methodologies that share that framework. Used to derive IT strategies and solution and enterprise architectures that are characterised by: Shared stakeholder understanding and commitment Clearly demonstrable business value Low development risk SD views architecture from four vantage points: business functional technical implementation Each view answers particular questions and is expressed in principles, models, and standards. When combined, the four ITSA views: enable SD to understand the needs of all stakeholders create a snapshot of what the solution should look like Stakeholder A person (or role) who has a significant interest in some aspects of a solution View A partial representation of a solution from the perspective of a related set of concerns
Architecture Analogy: Building a House Who do you go to first, once you have made up your mind to take a shot at building your own house? Do you go to the bricklayer, or the interior decorator, or to the kitchen-supplier? No, of course not. You go to someone with whom you can discuss all the key ingredients that go into the equation, Someone who can help you to look at this from all sides, in a coherent way and who knows about the decision steps to be taken. Someone who helps you build and maintain an integral picture of what you want to achieve, a picture that helps you to make your decisions and to communicate with all the different parties which are involved. In short, summing it all up, you go to an architect. How does the architect help you? He/she builds a high-level picture, a concept of the house in it’s environment , based on questions that you have to answer. But the architect knows what questions to ask, how to organise those questions and he/she can provide useful knowledge about bandwidths for the answers. This high-level picture we call architecture and it will be organised in different views, representing major aspects of the house. Each view can be divided into sub-views to create the architectural concept as follows.
Primary stakeholders Project sponsor Directors or “C” level – Sales and Marketing, Finance, IS/IT, HR, and so on Line of Business managers Content (drivers, issues, pressures at business level) Business objectives, strategy/direction/focus, strategic intents and associated initiatives Stated business core competencies Business governance, alliances, partnerships Sourcing strategies (both business and IT) Stakeholder targets and profiles Globalisation/localisation Competition Legal context Standards Client’s customers
Primary stakeholders System users Business process designers Information modelers Content (What will the system do? What information will it provide?) Overall view of information system operation, uses, capabilities, services, attributes, related systems, features, workflow What qualities must the overall system have and to what degree? For example, how many “9s” of availability are needed (“3 9s” = 99.9% uptime)? Independent of information technologies, products, and implementation A useful fact: 5 9s of availability corresponds to 5 minutes of downtime in a year.
Primary stakeholders Solution developers Technology consultants Subsystem suppliers Content (how, in general, the system will be realised with IT components) View of the applications, data, interfaces, component relationships, infrastructure Focus on how the system qualities or attributes (such as performance, availability, scalability, security, evolvability, management, and so on) will be achieved Independent of specific products and vendors (to the extent possible)
Primary stakeholders Business managers (they should decide rollout priorities) Project manager Solution developers Solution testers Solution deployers and operators/managers Content (with what, who, where…) With which products and other components? Configured how? In what organisation and locations? Using which processes? According to what plan (focus on staging/roll-out)? View of the existing and/or known future technical and organisational constraints
The SD architecture methodologies are based on the ITSA framework. The SD architecture methodologies are usually used within the context of a custom engagement or a particular technology practice. However, ITSA is useful in any application or technology domain. Solution Architecture Concept is a consulting workshop that sets overall scope and direction for the architecture, aligning business needs with proposed IT investments, and secures buy-in of stakeholders. Solution Architecture Blueprint is a detailed architectural description of a project, initiative, or enterprise architecture with sufficient detail to guide investments and implementation. Solution Architecture Concept A consulting workshop that sets overall scope and direction for the architecture, aligning business needs with proposed IT investments, and secures buy-in of stakeholders Solution Architecture Blueprint A detailed architectural description of a project, initiative, or enterprise architecture with sufficient detail to guide investments and implementation
When combined, the four ITSA views: Enable SD to understand the needs of all stakeholders Create a snapshot of what the solution should look like
This information is a preview of what will be discussed in the next few sessions. Key stakeholders include owners, users, builders, and operators. The four views match these main stakeholder categories.
Pure engineering focuses on the scientific, repeatable aspects of the work. Engineering is directed at tradeoffs and optimisation. Engineering usually involves clearly defined milestones, a well-defined methodology, meeting specified requirements within a well-defined cost structure and contractual agreement. Solution architecting attempts to “steal” from both Art and Science. The solution architect works as a trusted advisor to the client; yet, he or she is typically employed by the vendor or contractor. Working with the client, the solution architect seeks to capture the client’s vision, using both standard engineering techniques and creative “art” to find a solution that works within the client’s context. The solution must be “good enough” and satisfy the client’s objectives, but it will not necessarily be optimal. Time is often a critical factor. The solution architect works throughout the life cycle (which is often iterative) to ensure that the key business and technical criteria continue to be met throughout the development and deployment of the solution. Solution architecting involves the need to be sufficient, and to satisfy, without attempting to be optimal or elegant. Often it is the 80:20 rule (80% of the effectiveness with 20% of the time and effort) from a technology standpoint. Close enough is often good enough, especially if that means that the client’s pressing business requirements are dealt with in a timely fashion. Close enough is also good enough if it means that the essential components of the architecture are addressed even if some of the non-critical details need to be worked out later (perhaps in a later version). SD is ready to assist clients across the entire development life cycle. Thus, through iterative enhancement, the solution can be optimised to whatever degree the client requires.
Workshops for different levels and stages: Strategic IT planning (Enterprise Technology Planning) Solution domain assessment, solution planning Workshop design model: Consider: subject matter experts present overviews of specific technology areas pertinent to the scope of the workshop (concepts, trends, and best practices) Focus: Define and capture business drivers, principles, models, standards Develop high-level sketch of solution approach Decide: Make key decisions and take actions to resolve issues Chart next steps You focus on drivers and principles. You are responsible for the models.
Solution Architecture Blueprint develops a comprehensive specification of the essential aspects of an information system within a particular context. Allows the designers to make tradeoffs in development and product / technology selections Covers the system’s purpose, functions, interfaces with elements in the system’s environment, constituent components and their relationships, principles of operation, properties, and means of construction and test Makes it possible to plan and execute a successful project
When combined, the four ITSA views: Enable SD to understand the needs of all stakeholders Create a snapshot of what the solution should look like
