Your SlideShare is downloading. ×
0
Approach To It Strategy And Architecture
Approach To It Strategy And Architecture
Approach To It Strategy And Architecture
Approach To It Strategy And Architecture
Approach To It Strategy And Architecture
Approach To It Strategy And Architecture
Approach To It Strategy And Architecture
Approach To It Strategy And Architecture
Approach To It Strategy And Architecture
Approach To It Strategy And Architecture
Approach To It Strategy And Architecture
Approach To It Strategy And Architecture
Approach To It Strategy And Architecture
Approach To It Strategy And Architecture
Approach To It Strategy And Architecture
Approach To It Strategy And Architecture
Approach To It Strategy And Architecture
Approach To It Strategy And Architecture
Approach To It Strategy And Architecture
Approach To It Strategy And Architecture
Approach To It Strategy And Architecture
Approach To It Strategy And Architecture
Approach To It Strategy And Architecture
Approach To It Strategy And Architecture
Approach To It Strategy And Architecture
Approach To It Strategy And Architecture
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Approach To It Strategy And Architecture

6,003

Published on

Published in: Education, News & Politics
0 Comments
14 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
6,003
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
709
Comments
0
Likes
14
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 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
  • Transcript

    • 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. Learn to love what you’ve been taught to fear… <ul><li>Change is constant </li></ul><ul><li>Everyday events send ripples throughout the organisation, and the IT that supports it. </li></ul><ul><li>Change is unexpected </li></ul><ul><li>A merger, new market opportunity, sudden shift in competitive landscape, new partner. </li></ul><ul><li>Change is disruptive </li></ul><ul><li>The goal is to minimise the impact of disruptions with an IT environment that is synchronised with the business. </li></ul><ul><li>Change presents opportunities </li></ul><ul><li>The ability to adapt to change is a key advantage in business. To survive, compete and win, enterprises must adapt. </li></ul>
    • 4. Darwin Reference Architecture Business strategy Business processes Management Infrastructure <ul><li>Brings standardisation to the entire IT environment </li></ul><ul><li>Eliminates vertical islands </li></ul><ul><li>Embraces heterogeneity and legacy IT environments </li></ul><ul><li>Uses automation to scale and reduce complexity </li></ul><ul><li>Virtualises all IT assets </li></ul><ul><li>Helps convert fixed costs to variable costs </li></ul>Applications
    • 5. Adaptive Enterprise Design Principles Integration Simplification Standardisation Modularity + + + <ul><li>Applied consistently across: </li></ul><ul><ul><li>Business processes </li></ul></ul><ul><ul><li>Applications </li></ul></ul><ul><ul><li>Infrastructure </li></ul></ul><ul><li>Reduce number of elements </li></ul><ul><li>Eliminate customisation </li></ul><ul><li>Automate change </li></ul><ul><li>Use standard technologies and interfaces </li></ul><ul><li>Adopt common architectures </li></ul><ul><li>Implement standard processes </li></ul><ul><li>Break down monolithic structures </li></ul><ul><li>Create reusable components </li></ul><ul><li>Implement logical architectures </li></ul><ul><li>Link business and IT </li></ul><ul><li>Connect applications and business processes within & outside the enterprise </li></ul>
    • 6. How Do We Define Solution Architecture? <ul><li>Benefits </li></ul><ul><ul><li>Aligns business and information contexts with architectural decisions </li></ul></ul><ul><ul><li>Ensures the solution that is built matches requirements, and will evolve with changing business needs </li></ul></ul><ul><ul><li>Provides a complete, clearly-scoped solution </li></ul></ul>Solution architecture is the essential, unifying concept of an information system and its effective deployment into an operational environment to solve a key business problem.
    • 7. CIO Balancing Act <ul><li>Mitigate risk: </li></ul><ul><li>Ensure security and continuity of internal business operations, while minimising exposure to external risk factors </li></ul><ul><li>Maximise return: </li></ul><ul><li>Improve business results; grow revenue and earnings, cash flow, and reduced cost of operations </li></ul><ul><li>Improve performance: </li></ul><ul><li>Improve business operations performance end-to-end across the enterprise </li></ul><ul><li>Increase customer and employee satisfaction </li></ul><ul><li>Increase agility: </li></ul><ul><li>Enable the business organisation and operations to adapt to changing business needs </li></ul>
    • 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
    • 10. Solution Architecture is Not Just… <ul><li>A detailed implementation plan </li></ul><ul><li>A set of product standards </li></ul><ul><li>For infrastructure </li></ul><ul><li>Concerned only with technology </li></ul><ul><li>An end in and of itself </li></ul><ul><li>These are parts of an architecture, but they are not an architecture by themselves. </li></ul>
    • 11. Approach <ul><li>Approach is a mature, fully supported suite of methodologies that enable the delivery of offerings and services that provides: </li></ul><ul><ul><li>A set of best-in-class methodologies to support for the management and delivery of business </li></ul></ul><ul><ul><li>One-stop shop for methods, tools, and techniques </li></ul></ul><ul><ul><li>Guides and templates </li></ul></ul>
    • 12. Approach to ITSA <ul><ul><li>Based on stakeholder participation </li></ul></ul><ul><ul><li>Organised as a set of four fundamental views </li></ul></ul>Stakeholders Technical view Functional view Business view Implementation view
    • 13. The Four ITSA Views – Building a House Analogy Business view Implementation view <ul><li>Why do I want a new house? </li></ul><ul><ul><li>residence, entertainment, business </li></ul></ul><ul><ul><li>affordability </li></ul></ul><ul><ul><li>location </li></ul></ul><ul><ul><li>independence </li></ul></ul><ul><ul><li>image </li></ul></ul>Functional view <ul><li>What should the new house give me? </li></ul><ul><ul><li>uses / room layouts </li></ul></ul><ul><ul><li>peace & quiet, security </li></ul></ul><ul><ul><li>garden, trees </li></ul></ul><ul><ul><li>garage, pet needs </li></ul></ul>Technical view <ul><li>How will it be built? </li></ul><ul><ul><li>foundation, framing, heat/ac, plumbing, ... </li></ul></ul><ul><ul><li>utilities: - electric, water, comms, roads </li></ul></ul><ul><ul><li>security systems </li></ul></ul><ul><ul><li>controls </li></ul></ul><ul><ul><li>materials </li></ul></ul><ul><li>With what will it be built? </li></ul><ul><ul><li>sourcing - suppliers - specific models </li></ul></ul><ul><ul><li>financing </li></ul></ul><ul><ul><li>phasing </li></ul></ul><ul><ul><li>moving </li></ul></ul>
    • 14. Business View <ul><li>Key questions: </li></ul><ul><ul><li>What are the internal and external drivers? </li></ul></ul><ul><ul><li>What are the business models and processes? </li></ul></ul><ul><ul><li>Who participates in the business processes? </li></ul></ul><ul><ul><li>What are the project goals? </li></ul></ul><ul><ul><li>How will the success of the solution be measured? </li></ul></ul>Why are we doing this? Agility QoS Cost Risk
    • 15. Functional View <ul><li>Key questions: </li></ul><ul><ul><li>What will the completed solution do? </li></ul></ul><ul><ul><li>How will it be used and what services will it provide? </li></ul></ul><ul><ul><li>What information will it provide? To whom? </li></ul></ul><ul><ul><li>What qualities must the solution have? </li></ul></ul>What should the solution do? Agility QoS Cost Risk
    • 16. Technical View <ul><li>Key questions: </li></ul><ul><ul><li>How will the system be structured and constructed? </li></ul></ul><ul><ul><li>What are the interfaces and other constraints? </li></ul></ul><ul><ul><li>What applications and data are needed? </li></ul></ul><ul><ul><li>What does the infrastructure look like? </li></ul></ul><ul><ul><li>What standards will apply? </li></ul></ul><ul><ul><li>How will the system qualities be achieved? </li></ul></ul>How should the solution work? Agility QoS Cost Risk
    • 17. Implementation View <ul><li>Key questions: </li></ul><ul><ul><li>What specific products and components, from which vendors, are needed to build the system? </li></ul></ul><ul><ul><li>How will the system be developed and deployed? </li></ul></ul><ul><ul><li>What validation methods will be used? </li></ul></ul><ul><ul><li>How will it be managed? </li></ul></ul><ul><ul><li>What is the source of funding? </li></ul></ul>With what will the solution be built? Agility QoS Cost Risk
    • 18. ITSA Framework and Methodologies Solution Architecture Concept Solution Architecture Blueprint ITSA Methodologies ITSA Framework
    • 19. ITSA Framework <ul><li>Business drivers, goals, and metrics (closely associated with the business view </li></ul><ul><li>Principles, models, and standards (associated with each of the four views) </li></ul>The fundamental architectural elements of the ITSA framework are:
    • 20. In Summary <ul><li>The approach for creating solution architecture is: </li></ul><ul><ul><li>Based on stakeholder participation </li></ul></ul><ul><ul><li>Organised as a set of four fundamental views </li></ul></ul><ul><ul><li>Motivated by key business drivers, goals, and metrics </li></ul></ul><ul><ul><li>Expressed as a set of principles, models, and standards </li></ul></ul><ul><ul><li>Linked to actions to ensure timely progress </li></ul></ul><ul><ul><li>Supported by an extensible framework of methods, tools, and techniques </li></ul></ul>Technical view Functional view Business view Implementation view
    • 21. Contrasting Solution Architecture and Project management <ul><li>Solution Architecture </li></ul><ul><ul><li>Defines engagement scope </li></ul></ul><ul><ul><li>Articulates the essential elements of the solution and work to be done </li></ul></ul><ul><ul><li>Defines resources needed to complete the work </li></ul></ul><ul><ul><li>Defines acceptance criteria for solution iterations and phases </li></ul></ul><ul><ul><li>… </li></ul></ul>What to do <ul><li>Project Management </li></ul><ul><ul><li>Keeps engagement within scope </li></ul></ul><ul><ul><li>Ensures the work breakdown structure covers all the essential elements </li></ul></ul><ul><ul><li>Ensures staffing, funding, and resources are available to support the work </li></ul></ul><ul><ul><li>Defines milestones, and schedule and ensures acceptance criteria are met </li></ul></ul><ul><ul><li>… </li></ul></ul>How to get it done
    • 22. Contrasting Solution Architecture and Traditional Engineering <ul><li>Traditional Engineering </li></ul><ul><ul><li>Finds optimal solutions to well-understood problems </li></ul></ul><ul><ul><li>More science than art, algorithmic in nature </li></ul></ul>Focused on delivery <ul><li>Solution Architecture </li></ul><ul><li>Finds satisfactory system concepts for ill-defined problems </li></ul><ul><li>More art than science, heuristic in nature </li></ul>Focused on client needs
    • 23. Solution Architecture Concept <ul><li>A rapid review of the key elements of a proposed solution, examining each of the four views </li></ul><ul><ul><li>Focus on business drivers/goals, principles, models, and standards </li></ul></ul><ul><ul><li>Determine feasibility of an effective solution based on obstacles and constraints </li></ul></ul><ul><ul><li>Purpose: define solution’s conceptual architecture to facilitate well-informed, rapid decisions and get shared stakeholder understanding of, and commitment to, the proposed solution </li></ul></ul>
    • 24. Solution Architecture Blueprint <ul><li>A detailed architectural description of a project, initiative, or enterprise architecture. </li></ul><ul><li>Works with you to: </li></ul><ul><ul><li>Establish an agreed-to, sufficient solution concept </li></ul></ul><ul><ul><li>Define, design, and document all essential features of the solution </li></ul></ul><ul><ul><li>Analyse the feasibility of the solution </li></ul></ul><ul><ul><li>Plan the implementation of the solution </li></ul></ul>
    • 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. More Information <ul><ul><ul><li>Alan McSweeney </li></ul></ul></ul><ul><ul><ul><li>[email_address] </li></ul></ul></ul>

    ×