1. Microsoft Architectural Frameworks Informational Session & Discussion
Gurpreet S. Pall
Sr. Director
D&PE Architecture Strategy
Microsoft Corporation
© 2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

2. Agenda Why architecture, enterprise architecture Industry models
4/19/2017 5:20 AM
Agenda
Why architecture, enterprise architecture
Industry models
Microsoft models
Example - using models to deliver artifacts
Microsoft platform value
Microsoft Operations Framework
Microsoft Architectural Framework – proposal
Discussion – minutes
© 2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

3. The Need of Architecture The Winchester “Mystery” House
4/19/2017 5:20 AM
The Need of Architecture The Winchester “Mystery” House
Let me tell you a story…………….
Back in 1884 the Winchester heiress (famous US rifle company – Sarah Winchester) was convinced by a spiritualist that constantly building the property would stop the ghosts of the people killed with Winchester rifles coming and haunting her.
The reaction was to build by employing builders and being obsessed with adding rooms. The house looks great in this front view – full of “character”!
Oops, where’s the architectural blueprint you may be thinking! (147 builders employed – 0 architects – project cost of $M5.5)
Some anomalies certainly exist as a result rooms, 40 bedrooms, 6 kitchens and 2 basements
They are just minor anomalies though compared to 65 doors to blank walls, 13 staircases going nowhere and 24 skylights in floors
NO ARCHITECTURAL BLUEPRINT EXISTS FOR THIS HOUSE – NEED I SAY MORE – MSA IS THAT ARCHITECTURAL BLUEPRINT (and not just instructions on how to install the components)
38 years of construction – 147 builders 0 architects
160 rooms – 40 bedrooms, 6 kitchens, 2 basements, 950 doors
65 doors to blank walls, 13 staircases abandoned, 24 skylights in floors
No architectural blueprint exists
© 2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

4. Why Enterprise Architecture
IT costs too much
Costs of managing complexity
Eliminate redundancy
Growing IT ecosystem
Demanding rate of change
Need for info sharing
Outsourcing (BPO)
Future-proofing
If you don’t have strong architecture strategy, everyone does their own thing and you end up with six kinds of servers and (software) platforms … you get silos of everything and that explodes your costs”
Andy Miller VP of Technical Architecture, Corporate Express

5. Definition of Enterprise Architecture
4/19/2017 5:20 AM
Definition of Enterprise Architecture
The enterprise architecture is the organizing logic for a firm’s core business processes and IT capabilities captured in a set of principles, policies and technical choices to achieve the business standardization and integration requirements of the firm’s operating model.
© 2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

6. Does Your IT Architecture Look Like…
4/19/2017 5:20 AM
Does Your IT Architecture Look Like…
“If the Federal Government continues to do what we have done, (i.e., build non-architected solutions), we will continue to get what we have (i.e., a non-interoperable, expensive, and ever challenging tangle of data, applications, and technology).”
Source: FEAF Version 1.1
Effective organization is critical to help us gain a full understanding of the complex world surrounding us. Standard and consistent organizing systems are used everywhere, from the Periodic Table of the Elements and the Biological Classification of Organisms, to the Dewey Decimal system in libraries. Such systems are also plentiful in the world of Information Technology. For example, the DNS system helps organize computers globally in a meaningful way, and file systems provide a directory structure to organize files in storage.
Enterprise-level software and system architecture are ripe for a similar organizing system. If you ask any group of technologists to describe the architecture of a system, you are likely to hear contradicting descriptions. Each person often has his or her own view of the system, which is accurate but different from the view of other technologists looking at the same system. A consolidated and consistent view of enterprise software-intensive systems could help technologists gain a shared understanding of the enterprise architectural space that is more complete and accurate.
(needed a) …blueprint to bring order to “spaghetti layer of applications, boxes and wires” Toby Redshaw VP of Strategy & Architecture Motorola
© 2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

7. Why do I need a framework?
Complexity
Scale
Other?
Effective organization is critical to help us gain a full understanding of the complex world surrounding us. Standard and consistent organizing systems are used everywhere, from the Periodic Table of the Elements and the Biological Classification of Organisms, to the Dewey Decimal system in libraries. Such systems are also plentiful in the world of Information Technology. For example, the DNS system helps organize computers globally in a meaningful way, and file systems provide a directory structure to organize files in storage.
Enterprise-level software and system architecture are ripe for a similar organizing system. If you ask any group of technologists to describe the architecture of a system, you are likely to hear contradicting descriptions. Each person often has his or her own view of the system, which is accurate but different from the view of other technologists looking at the same system. A consolidated and consistent view of enterprise software-intensive systems could help technologists gain a shared understanding of the enterprise architectural space that is more complete and accurate.
© 2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

8. Many Schools of Thought
4/19/2017 5:20 AM
Many Schools of Thought
Industry models
Zachman Framework
Meta – Enterprise Architecture
Microsoft models
Microsoft solutions framework model
Software factories
Module map & Motion Methodology
Using a model to deliver artifacts
Enterprise Architectural Space Organizing Table (EASOT)
In this section a short overview is provided to demonstrate the pervasiveness of Enterprise Architecture in the current business landscape. _________________________________________________________________________
IEEE 1471 source of viewpoints and views
What we want to get the students to understand with the next few slides is that the word architecture is a much misused and maligned term. Each person or vendor describes what they are doing as an architecture, from a software design for a specific module, to a systems development life cycle methodology. We are not making any judgment on who is right or wrong, but merely want to sensitize the student that one of the questions that they need to ask whenever they hear the term “architecture” is – “what do you understand or mean by the term?”
The list is thus not exhaustive at all, but is merely selected as examples of the different focuses that are likely to be encountered in the marketplace.
Development by Rational Software
4 Views:
Logical,
Implementation
Process,
and deployment
+1 View:
Scenarios – here UML is used to demonstrate how the application will be used and is a check and balance for the other 4 views
Kruchten writes in his white paper that:
“The 4+1 View Model organizes a description of a software architecture using five concurrent views, each of which addresses a specific set of concerns. Architects capture their design decisions in four views and use the fifth view to illustrate and validate them.”
The approach is flexible in the sense that the logical view may consist of an Object Model if object oriented design techniques are used or it may consist of a Logical Data Model if the system is a data processing system.
Reference:
Kruchten, P, "The 4+1 View Model", Rational Software User's Group, Orlando, FL, 1998.
© 2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

9. Understanding the Zachman Framework for EA
Data
(What)
Function
(How)
Network
(Where)
People
(Who)
Time
(When)
Motivation
(Why)
Scope (Ballpark) view
Owners View (Enterprise Model)
Designers View (System Model)
Builder’s View (Technology Model)
Overview of the Zachman Framework In his 1987 paper, "A Framework for Information Systems Architecture," John Zachman refers to the increasing difficulty of managing information systems. Some of the contributing factors he identifies are the increasing size and complexity of these systems, coupled with the tendency to distribute them as more enterprise operations are automated. He then emphasizes the importance of information systems architecture in bringing structure to these decentralized systems.
According to Zachman, good information systems architecture is derived from the information system strategy, which, in turn, is determined by the business strategy. He implies, therefore, that the information systems should support the business objectives of the enterprise, but he does not expand on a strategic planning process. His model describes the deliverables (artifacts) of a software engineering process. He identifies two different kinds of representations which, when used in combination, precisely describe the nature and purpose of these deliverables within the organizational context.
First Representation: The Human Perspective The first representation addresses the different perspectives, or views, of the people involved in information system development. Zachman derives these perspectives by analogy from the models used in the construction and product engineering industries. Thus, he identifies three fundamental architectural views necessary for the development of a product:
Owner's view
Designer's view
Builder's view
He then identifies three more views to accurately depict all development stages for the information system artifacts within the enterprise:
Scope, or ballpark, view
Out-of-context view
Operational view
Each view is a description from a particular perspective and has a representation (a model or functioning system), as indicated in the graphic below. Here is a brief description of each view and model/functioning system:
Scope (Ballpark) View. This view describes the business purpose and strategy, which defines the playing field (ballpark) for the other views. It serves as the context within which the other views will be derived and managed.
Owner's View (Enterprise Model). This is a description of the organization within which the information system must function. Analyzing this view reveals which parts of the enterprise can be automated.
Designer's View (System Model). This view outlines how the system will satisfy the organization's information needs. The representation is free from solution-specific aspects or production-specific constraints.
Builder's View (Technology Model). This is a representation of how the system will be implemented. It makes specific solutions and technologies apparent and addresses production constraints.
Out-of-Context View (Detailed Models). These representations illustrate the implementation-specific details of certain system elements: parts that need further clarification before production can begin. This view is less architecturally significant than the others because it is more concerned with a part of the system than with the whole.
Operational View (Functioning System). This is a view of the functioning system in its operational environment.
A common misconception is that there is a progression within the two sets of views from abstract to more detailed representations of the product. Zachman emphasizes that each view is distinct and has a unique nature and purpose. Within each of these views the level of detail can be adjusted accordingly. What is useful to the owner might not be at all useful to the builder, no matter how detailed it is. Similarly, the owner might not be able to understand the designer's models, irrespective of the level of abstraction, simply because they describe a completely different view of the system.
Second Representation: Six Categories
The second product representation distinguishes different categories of the system. These categories are used to classify relevant characteristics and emphasize different aspects of the system. Each focus provides a different, product-centric view of the nature of the system, which identifies related characteristics and suppresses unrelated ones. Although these different views all relate to the same system, they remain isolated from each other:
What. This describes the system contents, or data, in the case of information systems.
How. The usage and functioning of the system are described here, including processes and flows of control.
Where. Spatial elements and their relationships are represented in this view, including system distribution.
Who. This depicts the people and organizational units interacting with the information system.
When. This view brings sequencing and timing to the processes and flows described in the How view. These two views are closely related to each other yet remain distinct to avoid unnecessary complexity. Concurrency is also addressed in this view.
Why. Motivations for creating the system and rules for constraining it are highlighted in this view. These constraining rules will most often be applied to the Why and How descriptions.
Combining the Two Dimensions By combining these two dimensions of representation into a matrix (Table 1) Zachman created his Framework, a powerful tool for analyzing software engineering deliverables. The distinct nature of the different representations along each of the axes makes it possible to precisely describe the nature and purpose of each cell. Using this description, an organization can assess the coverage of its software development process and evaluate the impact of new tools and techniques within the context of both business and information system strategies.
Out of Context View (Detailed Model)
Operational View (Functioning)
© 2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

10. 4/19/2017 5:20 AM
Hierarchical matrix views of the enterprise from strategy to systems
Features:
6 Abstractions:
Data, Function, Network, People, Time, Motivation
6 Perspectives
Scope, Enterprise Model, Systems Model, Technology Model, Detailed Representation, Functioning System
The Enterprise Architecture Framework is a representation of the artifacts of an enterprise that is significant in the management of the enterprise. It should be noted that Information technology is but one of the aspects that is normally addressed in this framework.
The purpose of the framework is to provide views of the artifacts of the enterprise in a way that:
simplify the reality in order to facilitate understanding and communication, and
focus attention on independent perspectives at various levels of detail for analytical purposes, but at the same time,
maintain an awareness of contextual relationships that are significant to preserve the integrity of the enterprise.
© 2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

11. Enterprise Architecture Meta Group
4/19/2017 5:20 AM
Enterprise Architecture Meta Group
Enterprise Strategy
Architecture
Business
Application
Portfolio
Information
Architecture
Technology
Architecture
The Principles of Architecture course is based on the recognition of four views or perspectives of a typical business, described by the acronym BAIT: Business, Application, Information and Technology. The BAIT ‘model’ is used here to introduce modern business challenges, and to lead the discussion in the direction of the need for EA.
Businesses continuously have to reinvent themselves
Applications exist in legacy forms and are challenged by new possibilities of doing things better and faster
Information is available from everywhere at any time – how to harness it, internalize it, add value to it and put it to use is escaping many businesses
Technology races ahead regardless: what technology to use for which applications, and how to ensure optimal use of the technology
This diagram, depicting the Enterprise Architecture of the Meta Group, shows how the strategy of the enterprise drives four separate, but interrelated architectures. Although there is an independency between the four components, they are integrated through the common enterprise strategy. The usefulness of the model for our purpose is that, while we are discussing changes in each of the four different architectures, we are constantly reminded of the influence which changes in any one or more of the architectures will have on the other.
Do not deviate onto the discussion of different Enterprise Architectures. The use of the Meta Group model is only to reinforce the BAIT concept, and it shows the integration of the four components nicely. It is important that the people understand how changes in any one or more of the components of the BAIT model will impact on the other components.
Business
Processes
Applications
Information
Infrastructure
The Meta Group Enterprise Architecture
© 2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

12. Microsoft Solutions Framework Strata In Microsoft Model
Contextual
Aimed at business executives
Aimed at business process owners
Aimed at architects and designers
Aimed at designers and developers
Conceptual
Logical
Each stratum in the architecture is designed to be totally understandable to the intended audience.
One of the aspects that determine the use of the Enterprise Architecture is the aspect that it acts as a “translator” between the different audiences in the enterprise.
The integration and deduction mechanisms that create the next level of perspective need to be formalized in order to ensure that an accurate and comprehensive translation takes place from the one stratum to the next.
Physical
© 2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

13. Adding Views Contextual Applications View Conceptual Information View
4/19/2017 5:20 AM
Adding Views
Business View
Applications View
Information View
Technology View
Contextual
Business strategies & processes
Applications to facilitate business process
Information needed to manage business
Technology to support business & application needs
Conceptual
Logical
Business View
What are the business strategies and processes that will make us successful
Application View
Which applications do we need to facilitate the business process and manipulate the information
Information View
What information do we need to manage in the business
Technology View
What technology is needed to support the information and application needs
Microsoft realizes that the enterprise operates in a environment that dictates the context of the enterprise. The context provides stimuli to all the aspects of the architecture.
New segmentation trends in business will require enterprises to re-visit the data that is retained about a client, while information privacy issues may pressure the enterprise to deal in a different way with this information.
New customer demands may provide opportunities for the enterprise to expand the business processes that it will deliver, while a loss of core competencies within the organization may constrain what the enterprise could sensibly deliver.
Better applications, such as Customer Relationship Management packages, that come unto the market may have a profound impact on how the enterprise manages the relationship with its stakeholders, but generic packages may constrain the delivery of specialized services because of built-in constraints.
New Technology, such as .NET may radically change the way that systems are developed and services are made available to clients. _________________________________________________________________________
Give examples of the newest initiatives that are forcing change in the way businesses perform their tasks. Address all four the areas and show how each of these changes permeates and reverberates through the whole business.
Explain that the application architecture is really deduced from the business architecture, and that no application has the right to existence without a valid business requirement.
Physical
© 2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

14. Logical Stratum Models
4/19/2017 5:20 AM
Logical Stratum Models
What type of applications do we need to put in place to support the business processes?
Who are the stakeholders in these applications?
What does the normalized data model look like for these applications?
Which application will create, read, update or delete data?
What types of technology do we need to enable these applications?
What is the distributed systems architecture going to look like?
What standards do we need to put in place?
The Logical stratum is the last layer that still isolates the business requirements from the technology that will support them. It defines the class of application, technology and data that must be supported, but does not instantiate it yet into constituent technology.
The logical models again provide the answer as to HOW the requirements (WHAT) identified in the conceptual models will be fulfilled.
A key deliverable that will constrain the options in the next stratum is a series of standards that will be adopted for the company. _________________________________________________________________________
In the Logical Strata, balance is everything:
Do too much at this stage, and the architecture initiative will degenerate into paralysis by analysis. It will also create very negative perceptions from the solution development group, as it will be seen as encroaching on their territory, and placing unreasonable and unrealistic constraints on the development projects
Do too little and each project will create its own version of data, technology or application that should be consistent across the enterprise.
There is no silver bullet or algorithmic approach that will tell you exactly what to define at this stage, and what to leave to the projects. Experience and logical thought are the only resources that will help you here.
Make sure that you have a consistent and well thought out message to defend the decisions that are taken with respect to the enterprise wide modelling of data, technology or application – they are bound to be challenged! Document these reasons and keep them in the Enterprise Architecture repository – six months down the line nobody will remember exactly what the decision criteria was.
Try to create a decision making model that will measure the benefit/risk of developing the models enterprise wide vs. leaving them to projects to define. If possible get executive sign-off of the model and the specific decisions to model enterprise wide.
_______________________________________________________________________
Get the participants to relate experiences from their own environment where they have run up against this balancing problem, either where too much was defined, or where too little was defined.
The example that is often used and that virtually everyone can associate with is the customer issue. In the past we left it to each project to define their concept of the customer. This resulted in customer data being stored in different databases to facilitate specific requirements for each application system. This fragmented storage strategy made it impossible to get a consolidated customer view. This has serious impact on the business.
Take for example a bank which has a customer with a $50 Million investment portfolio in the back, but he/she also has a credit card facility of $10’000. The risk profile in this client is extremely positive, but because the credit card division has no way of identifying the customer as the same individual as with the investment portfolio. If the customer gets into arrears on his credit card, an aggressive credit controller could very well compromise the client to such an extent that he/she moves the total business to another institution. Other customer segmentation and profitability analysis opportunities are also lost due to the fragmented customer view
This problem is so serious that a whole industry of Data Warehousing has been created to consolidate the information into a single consolidated view.
The Enterprise Architecture, however, tries to identify these cross-enterprise entities beforehand and then designs and instantiates them for use by different projects.
The projects do not own these entities, though, the enterprise does
© 2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

15. Logical Stratum Models
4/19/2017 5:20 AM
Logical Stratum Models
Entity Relationship Models
Class Models
XML Schemas
CRUD Affinity Matrices
Logical
Logical Data
Model
Application
Architecture
Distributed
Systems
Architecture
None of the models in the Logical Stratum should come as a surprise, they are all very well established paradigms that we use in every day systems design
The Data models can take the form of ERDs or Class models. It is also important at this stage to define the interfacing schemas, such as XML schemas for the data entities that we know will be used throughout the enterprise.
The Distributed Systems Architecture defines the technology services that is needed to support the applications that are required to fulfil the business requirements. Creating the DSA is iterative in conjunction with the Applications Architecture.
The Application Architecture consist of a matrix of business functions allocated to services defined in the DSA.
A Create, Read, Update, Delete (CRUD) matrix is used to relate the data to the applications and by performing affinity analysis provides a rudimentary sequence of project to ensure that systems that create data is developed before the systems that use data
Technology Services Portfolio
Distributed Systems Architecture Model
Function/Application Affinity Matrices
© 2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

16. Viewpoints DSLs Patterns Processes Frameworks Components Aspects
Transforms
Constraints
Assess
Design
Implement
Plan
Run
Strategic
Objectives
Manual Procedures
Business
Business Processes
and Entities
Services, Messages,
Contracts, Schedules
XML, Database, Classes,
Code
A common approach is to use a grid, like the one illustrated in Figure 6. The columns define concerns, while the rows define levels of abstraction. Each cell defines a perspective or viewpoint from which we can build some aspect of the software. For example, for a 3-tiered application, one cell might define an abstract viewpoint on the presentation tier, a second might define an abstract viewpoint on the data tier, and a third might define a concrete viewpoint on the data tier, used for developing database schemas. Once the grid has been defined, we can populate it with views that comprise the development artifacts for a specific software product.
Of course, a grid can be used to build more than one software product. Before it has been populated with specific views, it defines the bill of materials required to build the members of a software product family. Taking a cue from software product lines, we can go one step further and add information to each cell, identifying production assets used to build the views required by each viewpoint, including DSLs, patterns, frameworks, tools, and micro processes.
The grid is not an innovation. What is novel is applying the grid to a product family, identifying production assets for each cell, and defining mappings between and within the cells that can be used to fully or partially automate development tasks. We must use first class development artifacts based on high fidelity languages, like XML, C# and SQL in order to provide this automation. For models, this means using DSLs, not general purpose modeling languages designed for documentation. In some cases, the artifacts described by viewpoints are models, but this is often not the case. They can be any source artifacts based on a formal language, such as high level work flow scripts, general purpose programming language source code files, WSDL files, or SQL DDL files.
Technology
Architecture
Logical
Data Center
Physical servers
and segments IT
© 2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

17. Set Of Related View Points… and artifacts for Model Driven Development
4/19/2017 5:20 AM
Set Of Related View Points… and artifacts for Model Driven Development
Business
Capabilities
Manual
Procedures
Technology
Architecture
Constraints
Reconciliation
Services, Messages,
Applications, Endpoints
XML, Projects,
DBs, Classes, Code
Logical
Data Center
Physical servers & segments
Deployment
Units
Abstraction/
Refinement
Constraints
packaged into
deployed on
Business Processes
and Entities
Reconciliation
This is called a software factory schema
Like a recipe for a specific type of application
A set of viewpoints related by mappings that support transformation, validation and traceability
Lists artifacts required to build that type of application and explains how to combine them
A software factory template is content that configures a development environment to build that type of application
Projects, patterns, frameworks, guidance
The configured development environment is the software factory
Integrates tools, process and content for that type of application
Software Factories are based on the convergence of key ideas in systematic reuse, model driven development, development by assembly and process frameworks. Many of these ideas are not new. What is new is their synthesis into an integrated approach that lets organizations with domain expertise implement the four part Software Factory pattern, building languages, patterns, frameworks and tools to automate development in narrow domains.
© 2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

18. Applications, Endpoints
4/19/2017 5:20 AM
Merging Models
Business
Applications
Information
Technology
Business
Capabilities
Manual
Procedures
Technology
Architecture
Constraints
Reconciliation
Services, Messages,
Applications, Endpoints
XML, Projects,
DBs, Classes, Code
Logical
Data Center
Physical servers & segments
Deployment
Units
Abstraction/
Refinement
packaged into
deployed on
Business Processes
and Entities
Contextual
Conceptual
Logical
View point – define types of artifacts
View BPM for orders
Physical
© 2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

19. Module Map – Business Capabilities
4/19/2017 5:20 AM
Customer Facing Channel Partners
Customers
Enterprise
Suppliers
1. Develop Product / Service
2. Generate Demand
5. Collaboration
3. Fulfill Demand
4. Plan &
Manage
Enterprise
3.1. Provide Service
3.2. Advanced
Planning
3.3. Procurement
3.3.1 Sourcing and Supplier Contract Management
3.3.2 Purchasing
Level 4
3. Fulfill Demand
3.3 Procurement
3.3.2 Purchasing
- Request
Resources
- Create
Purchase
Requisitions
Request Resources
Create
Purchase
Requisitions
Business capability modeling
Business process modeling
3.4. Produce
Product
Receiving of Indirect / Capital Goods and Services
3.5. Logistics
Logistics Providers
Financial Service Providers
© 2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

20. 300 capabilities modeled and described
4/19/2017 5:20 AM
300 capabilities modeled and described
© 2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

21. DECOMPOSITION FRAMEWORK EXAMPLE DECOMPOSITION
Motion starts with a high-level, objective view of business, and allows capability decomposition
HIGH-LEVEL VIEW
DECOMPOSITION FRAMEWORK
EXAMPLE DECOMPOSITION

22. Example - Model For Pattern Identification
Business Architecture
Integration Architecture
Application Architecture
Extended
Platform
Enterprise Architectural Space Organizing Table
As enterprises respond to specific business initiatives, they produce many artifacts that capture architectural decisions, including: plans, notes, models, scripts, and code. Different roles in your enterprise use these artifacts to view the enterprise architecture in different ways. The potential for reuse increases if you have a meaningful way of organizing these artifacts.
Organizing the artifacts is a complex task, particularly as the enterprise and technologies change. Examining the space for all stable elements and cross-correlating all the relationships between elements would result in a multi-dimensional table that is not easy to display. A two-dimensional table allows you to analyze enterprise software-intensive systems in an intuitive way.
The Enterprise Architectural Space Organizing Table is such a two-dimensional table that captures and organizes business artifacts according to the decisions that produce them. The organizing table defines architectural viewpoints as rows, and interrogatives as columns. Figure 1 shows the basic structure of the organizing table. The particular rows and columns are discussed later in this paper.
Figure 1. Organizing table structure
As you will see later, the choice of rows for this organizing table provides a particular focus on the enterprise information space. The organizing table is intended to:
Provide a comprehensive view of the architecture space. The description is designed to organize architectural elements and demonstrate the relationships between them.
Be specific to enterprise software intensive systems. You may choose to extend the description to meet the needs of your enterprise.
The organizing table builds on four key pieces of work: The Zachman Framework for Enterprise Architecture [Zach], IEEE 1471 [IEEE], Andersen Consulting's Enterprise Information Architecture [Andersen], and test-driven development. Like the Zachman Framework, this table uses interrogatives as columns and roles as rows. This table, however, shows a higher degree of granularity in the rows and a higher degree of specificity in the artifacts contained in each cell. Also, based on the principles of test-driven development, this table includes an additional column that identifies the test of success for every row. Ideally, for any given row, the artifacts contained in the Test column should trace to the artifacts contained in the Purpose column for validation.
The organizing table groups rows together in levels of architecture, which shows the influence of the Enterprise Information Architecture framework. This grouping of rows exposes the overall alignment and traceability between business and technology. Within each row are discrete viewpoints, which are influenced by the IEEE 1471 architectural standard description. Together, these elements produce a highly granular map of the enterprise space that is organized by viewpoints and interrogatives.
One of the main strengths of the organizing table is that you can use it to store many different kinds of artifacts. By extracting, distilling, and abstracting the information contained in the traditional artifacts associated with enterprise software-intensive systems, you can produce patterns, practices, and guidance for your enterprise. You can then store these patterns in the organizing table. For more information about storing patterns in the table, see "Using the Table to Organize Patterns," later in this paper.
Operational Architecture
Development Architecture
© 2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

23. Add Interrogatives … Purpose (Why) Data (What) Function (How) Timing
(When)
Network
(Where)
People
(Who)
Scorecard
(Test)
Business Architecture
Integration Architecture
Application Architecture
Operational Architecture
Development Architecture

24. 4/19/2017 5:20 AM
Add Roles …
Architectural Viewpoints and Roles (Rows of the Organizing Table)
The organizing table divides enterprise architecture into five broad enterprise viewpoints. These views appear in the table as rows, which are organized from general to specific as you scan them from top to bottom. The viewpoints are:
Business architecture
Integration architecture
Application architecture
Operational architecture
Development Architecture
Although the viewpoints are a useful means of broadly categorizing architectural artifacts, the organizing table goes one step further by dividing the viewpoints according to specific roles that correspond to individuals with a particular skill set. As mentioned earlier, this additional detail allows you to trace the alignment of artifacts across the table.
Note   It is likely that the individuals in your enterprise do not map directly to the roles defined here. In a large enterprise, a role listed here might be assigned to a team (for example, architecture team). Conversely, one person may be responsible for many roles in a smaller enterprise. Nonetheless, most enterprise systems are viewed from the perspective of each of these roles at some point in time, and these roles can influence how you think about architectures as a whole. The following paragraphs examine the viewpoints and the roles they contain in more detail.
Business Architecture Viewpoint
The business architecture viewpoint provides a basis for the other architectural viewpoints. Enterprise software exists to provide business value to your enterprise and must align with your business objectives. Without a well-defined business architecture in place, any attempts at enterprise architectures are likely to involve reactive, improvised technology decisions.
The business architecture viewpoint consists of the following roles:
CEO
General Manager
Process Owner
Process Worker
Integration Architecture Viewpoint
The integration architecture viewpoint is concerned with integrating systems that run in the enterprise inside and outside of the firewall. A simple enterprise may need only a few independent applications to run their business, but many enterprises need to integrate their applications both inside and outside the firewall. Inside the firewall, classic enterprise application integration (EAI) approaches are used to integrate systems at the data, function, API, and presentation levels. Often a message broker architecture is developed to perform intelligent routing, transformation, and business rule processing. Outside of the firewall, enterprises are connecting with other enterprises to create extended enterprise networks of trading partners that have cross-enterprise integration needs. This is the domain of business-to-business (B2B) integration servers (BizTalk) and Web services interoperability frameworks, which are designed to integrate multiple businesses at the process level.
The integration architecture viewpoint consists of the following roles:
Enterprise Architect
Designer
Developer
Application Architecture Viewpoint
The application architecture viewpoint contains all of the system and software elements necessary to run an executable application, such as databases, Web servers, application servers, networks, presentation frameworks, components (both infrastructure and custom), run-time frameworks, business logic, and the applications themselves. Any applications used to produce business value are really executable knowledge or executable business process. People interact with these applications through various interfaces and perform some portion, or all, of a business process using an automated, executable tool.
The application architecture viewpoint consists of the following roles:
Architect
Operational Architecture Viewpoint
The operational architecture viewpoint is concerned with operating the production system in a stable, secure, scalable, predictable, and managed fashion. This category contains elements related to event, remote and performance management, user administration, backup, monitoring, and tuning.
The operational architecture viewpoint consists of the following roles:
Systems Architect
Systems Engineer
Development Architecture Viewpoint
The development architecture viewpoint is concerned with implementing the other architectures. Applications must be built and maintained in a systematic, efficient manner. The development architecture is composed of elements related to this effort, such as design and development tools, repositories, build master utilities, test suites, tracking tools, and other tools.
The development architecture viewpoint consists of the following roles:
Configuration Management Engineer
Buildmaster
Test Engineer
© 2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

25. Enterprise Architectural Space Organizing Table
4/19/2017 5:20 AM
Enterprise Architectural Space Organizing Table
Architectural Space Interrogatives (Columns of the Organizing Table)
Although viewpoints and roles provide discrete perspectives into the architecture, you can provide further granularity in the architectural space by categorizing artifacts according to generalized questions that are related to the business initiatives that produce the artifacts. These questions, or interrogatives, form the following columns of the organizing table:
Purpose (Why). What is the reason for the architectural decision made in response to the initiative?
Data (What). What information is required by or will be produced as a result of the decision called for in the initiative?
Function (How). How do the architectural decisions made in response to the initiative work?
Timing (When). When do events or actions called for, or recognized by, the decision take place?
Network (Where). Where do the products of the initiative reside?
People (Who). Who benefits from, or is otherwise affected by, the initiative? What is the interface through which that effect happens?
Scorecard (Test). How do you know that the purpose of the initiative has been achieved?
The order of the columns is arbitrary, although it is useful to have the purpose column on the left, because it defines the reason for the architectural decision.
© 2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

26. Enterprise Architectural Space Organizing Table

27. Pattern Model

28. Integration Topologies

29. MOF Process Model and SMF’s
4/19/2017 5:20 AM
MOF Process Model and SMF’s
The process model is all about driving due consideration through IT operations and having a standard approach to managing process.
The service management functions within the 4 quadrants of changing, operating, supporting and optimizing are a way of collecting processes into a given structure (in this case like-activities) and given taxonomy (notice the ITIL terminology) and then understanding the inter-relationships between them.
Service Management Functions
IT SMFs are the core of the MOF process model. Although no SMF is exclusive to a given quadrant in MOF, each SMF has a “home” quadrant or primary planning and execution quadrant. Grouping SMFs with a primary MOF quadrant is a more intuitive way to introduce an SMF in the context of the process model. The following is a comprehensive list of MOF SMFs along with their description.
Changing Quadrant – SMFs in the changing quadrant serve to align change in the production environment with IT business drivers. By instituting a formalized process for identifying needed changes and releasing secure, compatible solutions, these SMFs help IT forestall a common, and often significant source of downtime and mitigation cost. Configuration management serves the entire suite of IT processes, by providing a detailed reference database of critical settings and configurations.
Operating Quadrant – Processes within this quadrant focus on maintaining a healthy IT production environment. SMFs here focus on performing routine scheduling, data backup, and directory refresh tasks. Beyond the routine, they also control bandwidth-intensive operations to minimize impact on system performance. A proactive set of best practices encourages operators to mitigate potential system failures before they occur, often utilizing enabling technologies such as Microsoft Operations Manager or other tools.
Supporting Quadrant – The processes and IT staff that work within the supporting quadrant comprise IT’s user and customer presence. Service desk is the first line of support for internal and external customer issues. Efficient and effective incident and problem management processes help business minimize support costs through automation, self-help, and the generation of beneficial change to improve system performance and to correct errors.
Optimizing Quadrant – Taking the longer view, processes in this quadrant focus on analysis of current system parameters and identification of improvements to reduce or control cost, enhance availability and recovery, improve consistency and quality of service, and maintain compliance with evolving security needs and requirements.
© 2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

30. What Did We Learn? Business and IT alignment Stakeholders, viewpoints
Architects need to understand other views, and translate
Strata – and need for details
Domain specific needs
There is no end to detail
Flexible – agile
Need to project views in the world of connected systems

31. Other EA concerns Journey vs. destination
Evolutionary vs. revolutionary approach
IT – fixed asset or liquid asset
Leading change
Cross-cutting concerns
Model and methodology
Your EA is unique

32. So Why “YAF” yet another framework?
Common context for conversation
Context for delivering guidance/artifacts
Meta context for existing frameworks
Ageless, timeless
Demonstrate power of software

33. Reconciling IT and Business
4/19/2017 5:20 AM
Reconciling IT and Business IT
Business
Business Practice
strategy
judgment
change
oversight
tradeoffs
insight
Applications
Business Functions
The traditional IT model separates into infrastructure and applications.
If you think about business, there are business functions which today are increasingly manifested in applications.
But there is also another dimension of business which are the everyday practices of gleaning insights, making decisions, being accountable, reacting to change, coordinating resources. These practices occur in the boardroom and on the front lines.
Many of today’s IT challenges stem from disconnects between business practices and applications. People talk about IT-business alignment as if these are two big ponderous things that with considerable effort can be brought together. Even a stopped watch is right twice a day…
Infrastructure
© 2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

34. Business Applications
4/19/2017 5:20 AM
The Agile Business
Decide
Act
Collaborate
Insight
Oversight
Business Practice
Business Practice
Applications
Business Functions
Business Applications
Infrastructure – efficient and flexible
Business Applications – connected, efficient and flexible
Business Practices – connected to the infra and apps
Infrastructure
Infrastructure
© 2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

35. Business Imperatives Core Business Practices Operational Efficiency
4/19/2017 5:20 AM
Business Imperatives
“Consistency”
“Understanding”
Operational
Efficiency
Customer
Intimacy
Core Business
Practices
Product
Leadership
Value
Chain
So as we think about top line, the ability to deliver new value, there are really a fairly basic set of things that everybody needs to do.
Operational Efficiency
We all care about our operational efficiency. Whatever it is that we're doing, we want to do that as efficiently as possible.
Economies of scale, consistency
Examples: Dell, Wal-Mart, UPS, JetBlue, telcos, utilities
Software solution: Integration, interoperability
Product Leadership
From a product standpoint, from a service standpoint, whatever it is that we offer, we want to be innovative there and have the best offerings on the market.
Product Innovation (“Break Through”)
Examples: BMW, Nike, Microsoft (?)
Software solutions: Fast time to market, flexible
Value Chain
From a partner ecosystem standpoint, whether it's dealers, whether it's distributors, whether it's suppliers, whether it's other partners, we want to have the most powerful value chain that we can.
Partner Ecosystem (“Connect To”)
Examples: Dell, Wal-Mart, Microsoft (?)
Software solution: Information Supply Chains
Customer Intimacy
And then from a customer perspective, we all want to do the best possible job we can serving our customers, understanding our customers; how do we find them, how do we retain them, how do we up-sell them, how do we service them, how do we satisfy them. It's a fairly basic set of operations from a business perspective.
Economies of scope
Examples: Nordstrom, Fidelity
Software solution: Digital Customer Relationships
Core Business Practices
And there also is this set of core business practices of how do we stitch all that stuff together, how do we discover things are changing in the marketplace, be it a change in customer taste, be it regulation, be it technology change, be it the macroeconomic environment; how do we assimilate those things and then go act on them across the different parts of the business.
And what's interesting is almost any business you look at has to do all these different activities but typically a company specializes in one of these different things. At Microsoft we'd say we're primarily a product innovation company. If you look at financial services or consumer products, they're probably most about customer intimacy. If you think about utilities or airlines or some manufacturers, they're really about doing things consistently and very, very efficiently over time. You could look in the value chain space, companies like Dell or Wal-Mart are really defined by the value chain that they've built out around them.
“Sense & Act”
“Innovation”
“Scale”
© 2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

36. Top-line Software Strategies
4/19/2017 5:20 AM
Top-line Software Strategies
Agile
Infrastructure
Digital Customer Relationships
“Consistency”
“Understanding”
Operational
Efficiency
Customer
Intimacy
Core Business
Practices
Digital Business
Practices
Product
Leadership
Value
Chain
And as we think about it, this is ever so slightly self-serving, because we're a software company, but we really do believe that software is where the magic happens. If you look at the technology spend, the investments that people make, software is a relatively small piece of that overall spend, typically about 10 percent of the overall IT spend. But the impact, the set of choices of those software choices the customers make can have a huge impact on their overall cost structure. It also has a huge impact on their overall value structure, what they're able to do with the underlying software. Is it flexible enough to allow them to adapt and evolve to changes as they happen? Increasingly software is where you…
Establish business insight and oversight
Capture business processes and intellectual property
Interact with customers and partners
Touch almost every business event or decision
Examples:
Operational Efficiency
On the operational efficiency side, the airline business is obviously a very, very competitive business. Jet Blue is a pretty interesting company.
Founded in March of 2000, not the best time to be starting up a business and really not the best time to be starting up an airline.
They've been a very profitable airline. Just by being profitable is a pretty impressive achievement in the airline business.
They spend about 1.4 percent of sales on IT. The industry average is about 5 percent. You could argue that that cost savings is really the difference between their profitability and their lack of profitability that some of their competitors see.
Well, those other airlines are in the position where they still have to compete with the cost structure that Jet Blue has.
And if you look at capital spending in at least the U.S., almost 50 percent of all capital investment goes into IT. So as companies are looking at ways to become more efficient, as they're thinking about the ROI on different capital spend, that's one area where we're not just talking about saving some money through server consolidation, but you can actually talk about a material impact on the business overall.
Customer Intimacy
I want to talk about customer intimacy and getting close to the customers, and this is really not so much a customer example today as the cautionary tale of what happened with Napster and Kazaa and Morpheus where that's an industry where there's an incredible customer relationship network that's been wired up in that particular space. The challenge is the record companies neglected to get wired up into that particular network.
And it's fascinating to look at the impact of technology on the traditional means of marketing. At the top level, customers are more educated than ever before. As end users spend more of their time online, we've seen advertising follow.
The initial display advertising wasn't very effective, so we saw pop-up ads. Pop-up ads began the pop-up ad blocker.
Something like 30 percent of all Internet users today have a pop-up ad blocker.
We expect that number will go over 50 percent by the end of the year.
Spam is another one. You could say it's the extension of direct response into the Internet. Today the spammers are winning, but there's a huge amount of investment to go take care of that.
The marketing model in some ways is getting turned on its head. We're seeing a move to much more relationship oriented marketing where you want to build that long-term relationship with the customer and give them enough value that they'll opt in to that particular relationship. We think increasingly software is the way that relationship is going to be driven.
Today obviously a huge amount of customer interaction goes on through the Web, but a lot of this is really self-service focused as opposed to improving the relationship. Over the next several years we're going to see software be much more proactive and the if the customer invites you into their world, that software is going to be able to reach out and connect with that particular customer.
Now, start to think about the software systems that make this work.
It's not just the interaction point, but we're going to see a transformation of Customer Relationship Management software to software that drives that end-to-end customer experience.
The ability to do analysis and segmentation on top of that.
Product Leadership
The third example is on the software side and there are lots of interesting ways to use software to do product innovation. There are people who are applying software to the process of innovation itself. So if you look at the automotive companies where they've brought the cycle to design and deliver a new car down from six, seven years to some of them are pushing two years, they use software and collaborative design to really speed up that particular process.
We're also seeing people add software to all kinds of interesting products that previously you wouldn't necessarily have thought of them as software companies. And Johnson Controls is a great example. They are, amongst other things, a manufacturer of heating and cooling widgets. So if you look inside the ducts on the ceiling here, there probably are some Johnson Controls widgets. They've actually added software to those things, wired them up over the Internet, and are now not just in the widget business but they're in the building management services business.
And that's a general theme that we're seeing around people who build products is they want to augment their product with a set of services.
Value Chain
The fourth example is one the value chain side. And I'm sure many of you are very familiar with all the work that's been down to build out global supply chains, the manufacturing that's happening on a global basis. It's software that really makes those things happen.
We think there's a next step, which is going to go beyond just the value chain or the supply chain that's focused on physical goods, parts, suppliers, but you're going to start to see an information supply chain.
A project we did with Merck where they are in the business of trying to discover new drugs and drug trials are very expensive; also their ability to do them very quickly or if they're not panning out kill them very quickly is an enormously important part of their business.
we built an information supply chain that wired together the patients, the doctors of those particular patients who are in the drug trial, Merck, and ultimately the FDA.
Literally they gave a blood pressure sensor to patients who are in a particular trial who could put that on their finger, collect some data, push that data up into the information supply chain.
They had the ability to monitor that in real time, so if there was an anomaly they could alert the particular doctor who's involved. They also aggregated all that data and had the ability to do lots of data mining, decide if things looked good, if things didn't look good, collect that data, push that to the FDA.
It had to span multiple domains. Nobody owned and operated all the pieces there.
Customers were using their own PCs to collect some of that data.
Doctors had their own systems
Merck had their own systems
The FDA had their own set of systems.
The ability to stitch those things together on a relatively dynamic basis and move the information up and down the value chain is enormously powerful for Merck. Merck actually is going to go sell this particular service to other pharmaceutical companies.
So if you think about these information supply chains, they exist everywhere. The relationships with dealers, with distributors, with suppliers; there are lots and lots of opportunities to think about cross-industry information flows, not just the information about physical goods that are out there.
Core Business Practices
The last example is around this idea of the core business practice. How do we bring all these things together and empower people to make great business decisions? A great examples here is a company called Abitibi-Consolidated, a natural resources company in Canada who owns number of paper mill and hydroelectric plants.
Empowered the guy who sits in the shed next to the hydroelectric plant to make decisions about what's the best use of their hydroelectric power that's coming off the dam; should they send it to their paper mill or are there other opportunities.
Built a system where the guy can sit in the shed and he's got a weather forecast, he can look at what things are expected to be temperature wise over the next week or so.
He has access to spot and futures information about the electricity market and the ability to control where the power coming off the hydroelectric plant is going.
In real time at 2:00 in the morning they make a decision to sell their power onto the grid or to use it in their own hydroelectric plant and it's a great example of using these different systems, bringing together all the assets to enable people to make important business decisions.
It's brought in about $100 million Canadian incremental revenue to this particular company and it's a great example of surfacing the right information so the people can make the decisions and then being able to act on them and ensure that those decisions are actually being carried out.
So we're pretty excited about these kinds of scenarios and the opportunity to work with customers to use technology to deliver top-line value going forward.
“Sense & Act”
“Innovation”
“Scale”
Software Enrichment
Information Supply Chain
© 2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

37. Microsoft Architectural Framework
Transformation
Business Imperatives
Core
Business
Practice
“Sense & Act”
Product
Leadership
“Innovation”
Operational
Efficiency
“Consistency”
Value
Chain
“Scale”
Customer
Intimacy
“Understanding”
Business: objectives, functions, processes
Application: portfolio used in the organization
Information: data entities and relationships
Technology: software, hardware, etc.
Digital
Business
Practice
Software Strategies
Software
Enrichment
Agile
Infrastructure
Information
Supply
Chain
Customer
Relationship
Connecting IT and business
According to NIST inefficiency in supply chain causes $5 Billion (1%) to the automotive industry every year – lack of integration in supple chain processes – addressable by better story on integration and interop using Web Svs
On-board telemetric – platform on-board systems – navigation, interactive - AAIA 60B on forgotten maintenance cost of s/w licensing will exceed cost of steel for the automotive.
Build-to-order: Custom configure and deliver the car within 2 weeks (Model T – choice of black) on-line, combined with telemetric systems, on-going relationship – improve customer sat
Operational efficiency: smart client connected to the different systems data aggregated
And as we think about it, this is ever so slightly self-serving, because we're a software company, but we really do believe that software is where the magic happens. If you look at the technology spend, the investments that people make, software is a relatively small piece of that overall spend, typically about 10 percent of the overall IT spend. But the impact, the set of choices of those software choices the customers make can have a huge impact on their overall cost structure. It also has a huge impact on their overall value structure, what they're able to do with the underlying software. Is it flexible enough to allow them to adapt and evolve to changes as they happen? Increasingly software is where you…
Establish business insight and oversight
Capture business processes and intellectual property
Interact with customers and partners
Touch almost every business event or decision
Examples:
Operational Efficiency
On the operational efficiency side, the airline business is obviously a very, very competitive business. Jet Blue is a pretty interesting company.
Founded in March of 2000, not the best time to be starting up a business and really not the best time to be starting up an airline.
They've been a very profitable airline. Just by being profitable is a pretty impressive achievement in the airline business.
They spend about 1.4 percent of sales on IT. The industry average is about 5 percent. You could argue that that cost savings is really the difference between their profitability and their lack of profitability that some of their competitors see.
Well, those other airlines are in the position where they still have to compete with the cost structure that Jet Blue has.
And if you look at capital spending in at least the U.S., almost 50 percent of all capital investment goes into IT. So as companies are looking at ways to become more efficient, as they're thinking about the ROI on different capital spend, that's one area where we're not just talking about saving some money through server consolidation, but you can actually talk about a material impact on the business overall.
Customer Intimacy
I want to talk about customer intimacy and getting close to the customers, and this is really not so much a customer example today as the cautionary tale of what happened with Napster and Kazaa and Morpheus where that's an industry where there's an incredible customer relationship network that's been wired up in that particular space. The challenge is the record companies neglected to get wired up into that particular network.
And it's fascinating to look at the impact of technology on the traditional means of marketing. At the top level, customers are more educated than ever before. As end users spend more of their time online, we've seen advertising follow.
The initial display advertising wasn't very effective, so we saw pop-up ads. Pop-up ads began the pop-up ad blocker.
Something like 30 percent of all Internet users today have a pop-up ad blocker.
We expect that number will go over 50 percent by the end of the year.
Spam is another one. You could say it's the extension of direct response into the Internet. Today the spammers are winning, but there's a huge amount of investment to go take care of that.
The marketing model in some ways is getting turned on its head. We're seeing a move to much more relationship oriented marketing where you want to build that long-term relationship with the customer and give them enough value that they'll opt in to that particular relationship. We think increasingly software is the way that relationship is going to be driven.
Today obviously a huge amount of customer interaction goes on through the Web, but a lot of this is really self-service focused as opposed to improving the relationship. Over the next several years we're going to see software be much more proactive and the if the customer invites you into their world, that software is going to be able to reach out and connect with that particular customer.
Now, start to think about the software systems that make this work.
It's not just the interaction point, but we're going to see a transformation of Customer Relationship Management software to software that drives that end-to-end customer experience.
The ability to do analysis and segmentation on top of that.
Product Leadership
The third example is on the software side and there are lots of interesting ways to use software to do product innovation. There are people who are applying software to the process of innovation itself. So if you look at the automotive companies where they've brought the cycle to design and deliver a new car down from six, seven years to some of them are pushing two years, they use software and collaborative design to really speed up that particular process.
We're also seeing people add software to all kinds of interesting products that previously you wouldn't necessarily have thought of them as software companies. And Johnson Controls is a great example. They are, amongst other things, a manufacturer of heating and cooling widgets. So if you look inside the ducts on the ceiling here, there probably are some Johnson Controls widgets. They've actually added software to those things, wired them up over the Internet, and are now not just in the widget business but they're in the building management services business.
And that's a general theme that we're seeing around people who build products is they want to augment their product with a set of services.
Value Chain
The fourth example is one the value chain side. And I'm sure many of you are very familiar with all the work that's been down to build out global supply chains, the manufacturing that's happening on a global basis. It's software that really makes those things happen.
We think there's a next step, which is going to go beyond just the value chain or the supply chain that's focused on physical goods, parts, suppliers, but you're going to start to see an information supply chain.
A project we did with Merck where they are in the business of trying to discover new drugs and drug trials are very expensive; also their ability to do them very quickly or if they're not panning out kill them very quickly is an enormously important part of their business.
we built an information supply chain that wired together the patients, the doctors of those particular patients who are in the drug trial, Merck, and ultimately the FDA.
Literally they gave a blood pressure sensor to patients who are in a particular trial who could put that on their finger, collect some data, push that data up into the information supply chain.
They had the ability to monitor that in real time, so if there was an anomaly they could alert the particular doctor who's involved. They also aggregated all that data and had the ability to do lots of data mining, decide if things looked good, if things didn't look good, collect that data, push that to the FDA.
It had to span multiple domains. Nobody owned and operated all the pieces there.
Customers were using their own PCs to collect some of that data.
Doctors had their own systems
Merck had their own systems
The FDA had their own set of systems.
The ability to stitch those things together on a relatively dynamic basis and move the information up and down the value chain is enormously powerful for Merck. Merck actually is going to go sell this particular service to other pharmaceutical companies.
So if you think about these information supply chains, they exist everywhere. The relationships with dealers, with distributors, with suppliers; there are lots and lots of opportunities to think about cross-industry information flows, not just the information about physical goods that are out there.
Core Business Practices
The last example is around this idea of the core business practice. How do we bring all these things together and empower people to make great business decisions? A great examples here is a company called Abitibi-Consolidated, a natural resources company in Canada who owns number of paper mill and hydroelectric plants.
Empowered the guy who sits in the shed next to the hydroelectric plant to make decisions about what's the best use of their hydroelectric power that's coming off the dam; should they send it to their paper mill or are there other opportunities.
Built a system where the guy can sit in the shed and he's got a weather forecast, he can look at what things are expected to be temperature wise over the next week or so.
He has access to spot and futures information about the electricity market and the ability to control where the power coming off the hydroelectric plant is going.
In real time at 2:00 in the morning they make a decision to sell their power onto the grid or to use it in their own hydroelectric plant and it's a great example of using these different systems, bringing together all the assets to enable people to make important business decisions.
It's brought in about $100 million Canadian incremental revenue to this particular company and it's a great example of surfacing the right information so the people can make the decisions and then being able to act on them and ensure that those decisions are actually being carried out.
So we're pretty excited about these kinds of scenarios and the opportunity to work with customers to use technology to deliver top-line value going forward.
© 2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

38. Transformation Business Application Information Technology
4/19/2017 5:20 AM
Business Imperatives
Core
Business
Practice
“Sense & Act”
Product
Leadership
“Innovation”
Operational
Efficiency
“Consistency”
Value
Chain
“Scale”
Customer
Intimacy
“Understanding”
Transformation
Business
Application
Information
Technology
Compliance
Systems
RFID
Enabled
Supply
Chain
Integration &
Interoperability
Using WS
Business Perspective
The business perspective views the architecture based on how the business works. It includes broad business strategies along with plans for moving the organization from its current state to an envisaged future state. The architect must design to support the following aspects of the EA:
Enterprise's high-level objectives and goals.
Business processes carried out by the enterprise.
Business functions performed.
Major organizational structures.
Relationships between these elements.
Application Perspective
The application perspective defines the enterprise's application portfolio and is application-centered. In this view the architect must specify the requirements applications that will consume the available information to support the business requirements by doing the following:
Describe automated services that support the business processes.
Describe the interaction and interdependencies (interfaces) of the organization's application systems.
Plan applications and revise old applications based on the enterprises objectives, goals, and evolving technology platforms.
Achieve common business objectives by linking users of different skills and job functions across organizations, services, information, and functionality.
Information Perspective
The information perspective describes what the organization needs to know to run its business processes and operations. In this perspective, the architect must construct:
Standard data models.
Data management policies.
Descriptions of the patterns of information production and consumption in the organization.
The information perspective also describes how data is bound into the work flow, including structured data stores such as databases, and unstructured data stores such as documents, spreadsheets, and presentations that exist throughout the organization.
Technology Perspective
The technology perspective lays out the hardware and software supporting the organization, including operating systems, desktop and server hardware, and so forth.
The technology view provides a logical, vendor-independent description of infrastructure and system components that is necessary to support the application and information views. The architect must understand the technology standards and services needed to execute the business mission. These standards and services include, but are not limited to:
• Topologies
• Development environments
• APIs
• Security
• Network services
• Database management system (DBMS) services
• Technical specifications
Digital
Business
Practice
Software Strategies
Software
Enrichment
Agile
Infrastructure
Information
Supply
Chain
Customer
Relationship
© 2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

39. Discussion Have you adopted an architectural frameworks?
Which one(s) and why?
Did you change/modify it?
Can you live with multiple frameworks from Microsoft?
What do you think of MAF?
Is it easy to understand?
What would you change/add/remove?

40. © 2004 Microsoft Corporation. All rights reserved.
4/19/2017 5:20 AM
© 2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.
© 2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.