1. Boundaryless Information Flow
19 September 2018
Boundaryless Information Flow
The Role of Architecture
Allen Brown
President & CEO
44 Montgomery Street
Suite 960
San Francisco, CA
94104 USA
Tel
(C) The Open Group 2002

2. Who we are You are architects and managers of architects
Technology architects
Information architects
Application architects
Business architects
Enterprise architects
I am a decision making CEO who sees the value of using architecture to make decisions
19 September 2018
(C) The Open Group 2003

3. Customer problem statement
19 September 2018
Customer problem statement
“I could run my business better if I could gain operational efficiencies improving
the many different business processes of the enterprise
both internal, and
spanning the key interactions with suppliers, customers, and partners using
integrated information, and access to that information.”
Based on the work of our members, we discovered that, like the customers who spoke today, they have similar goals for their businesses. At the highest level, they strive to provide better quality products and services to their customers in a faster and more cost-effective manner. To achieve this they must develop the ability of smaller organizations to respond more quickly to business problems, anticipate customer needs, and identify and act upon revenue-generating opportunities earlier.
Our information systems must help to achieve these goals by supporting the business and by providing access to integrated information to their employees, customers, and partners. That access and even the way the information is used and displayed changes even more rapidly than the business requirements themselves as teams form and disperse to respond to business crises and opportunities.
While many organizations strive to meet these goals and objectives, their information systems lack the flexibility to support dynamic changes in business processes. They simply do not allow information to securely flow across applications, functions, and organization boundaries to deliver information when and where it is needed at any given moment.
Who would have thought that those applications we were implementing 20 or 30 years ago were going to be around today to give us grief. And if we had known then, that in the future these applications would have been required to provide information for integration with others – would we or could we have done anything different?
Link: We have observed many similarities in customer problems across industries in the commercial sector and even into the government sector
Source: “The Interoperable Enterprise”
19 September 2018
(C) The Open Group 2003
(C) The Open Group 2002

4. A common problem Sell Space Internal Space Buy Space Systems
19 September 2018
A common problem
The cause:
multiple systems, conceived and developed individually
Compounding the problem:
cross-functional teams continuously forming, new business partners, stove-piped information
Sell Space
Customer Support
Selling
Internal Space
Manufacturing
Legal
Finance
Assembling
Partner 1
Partner 2
Partner 3000
Appl 1
Appl 2
Appl 50
Online Systems
Buy Space
Design
Systems
Procuring
ERP
Systems
Requirements
Systems
Systems
Procurement
Systems
19 September 2018
(C) The Open Group 2003
(C) The Open Group 2002

5. Vision Boundaryless Information Flow
achieved through global interoperability
in a secure, reliable and timely manner
Boundaryless does not mean there are no boundaries – it means that boundaries are permeable to enable business.
19 September 2018
(C) The Open Group 2003

6. Boundaryless Information Flow …
19 September 2018
Boundaryless Information Flow …
Sell Space
… needs access to information that was not necessarily designed to leave its original domain.
Processes
Customer Support
Selling
Internal Space
Manufacturing
Legal
Finance
Assembling
Online Systems
Buy Space
Design
Systems
But looking at the details, even in an oversimplified way, one can see that the “systems” supporting these processes are not single systems - there are many. In order to get the operational efficiencies a level of integration must occur at 2 points. Integrated information must happen to provide a single view of information within a given vertical area such as procurement, or requirements, or enterprise resource planning information, … Additionally to support end to end process improvements an integrated view must be provided horizontally. These two points are integrated information and access.
Note these systems need not be technology systems, they can be organizational systems. The need to integrate the information and provide access exists despite of the level of computer technology that exists in the environment.
Procuring
ERP
Systems
Requirements
Systems
Systems
Procurement
Systems
19 September 2018
(C) The Open Group 2003
(C) The Open Group 2002

7. Technologies create boundaries…
19 September 2018
Technologies create boundaries…
Infrastructural
Organization of the interconnecting and underlying facilities
Structural
System growth is limited by the “strength” or scalability of its structure
Architectural
Differently architected technologies often don’t “fit” with each other
Semantic
Different ways of representing the same thing
Infrastructural:
For example, in telephony, subscribers are connecetd to central offices serving specific geographic areas; they in turn are interconnected with each other and with long distance centers in a local area. Long distance centers are the points of interconnection for the local areas. The internet has a similar organization. IT systems are organized into data centers. Middleware infrastructures are often organized into domains or cells. Security services are organized into local domains and foreign cross-registrations (language is sensitive here)
Structural:
As in civil engineering or the construction of buildings, systems are limited in size or scope by the nature of their structural elements.
Architectural
Architecture can be an egocentric thing. (Consider, among “real” architects, Frank Lloyd Wright, and le Corbusier.) But great architectures, while working over a wide variety applications, may not mesh well with each other. In IT, we can look at the gratuitous battles over middleware architectures, like the intentionally introduced incompatibilities between DCE and CORBA, or among the enterprise networking architectures of IBM, DEC and Sun. Some of the differentiations between and among architectures serve legitimate purposes, however. Integrating new “materials,” (as did the International Style in “real” architecture) or meeting new needs (as with the architectures that developed around the construction of trainsheds and large industrial facilities.) And so on.
Semantic
Speaking different languages causes problems, as we know. On the other hand, specialized languages are essential to certain advanced disciplines. Lawyers have a language, as do economists, painters, musicians, theologians, computer scientists, and so on. Liturgical use of language is yet another example of using “technical” boundaries of syntax and semantics intentionally to achieve certain effect.
19 September 2018
(C) The Open Group 2003
(C) The Open Group 2002

8. The role of architecture
“Architecture is fast becoming one of the main instruments for improving Business IT Alignment.”
“It is time to broaden our view and build systems that last and that keep delivering value to the business. Business and IT Architecture play a pivotal role in achieving this goal..“
Raymond Slot M.Sc, MBA, Principal Consultant and Enterprise Architect for Cap Gemini Ernst & Young
19 September 2018
(C) The Open Group 2003

9. Architecture role in the life-cycle
Plan
Design
Build
Roll-out
Maintain
Post
Review
relationships and dependencies
recall trade-offs & rationale
communicate
document current situation
capture business requirements
prioritize
communicate
guide procurement, development and integration
control design changes
system integrity
communicate
technical needs
criteria for product selection
assess trade-offs/priorities
communicate
gain early user buy-in
manage expectations
communicate
sound basis
SMART objectives
communicate
19 September 2018
(C) The Open Group 2003

10. Boundaryless Information Flow - Business Taxonomy
19 September 2018
Boundaryless Information Flow - Business Taxonomy
Security Policy
Mobility Policy
Phone Books/Directories
Information Consumers
Development
Organization
Brokers
Management
Organization
The current view of the architecture reference model for Boundaryless Information Flow is depicted here. This picture was derived from the business issues already presented.
First we understand that there are human and computing actors in the business environment that need information. These are information consumers. Second we understand that there are human and computing actors that have information and these are called information providers. Information consumers need technology services to help them request information. Information providers need services to help them liberate the information in their control. Thus information consumer services and information provider services.
Additionally we have established that there are numerous types of information consumer and information provider, much like in the stock market industry where brokers serve the purpose of helping information consumers get access to all the information they need from all the different information providers. This we have Brokering services in the reference model.
Additionally in the business environment we understand there are development organizations, outsourced or in-house, and there are management organizations. These organizations are supported by tools and utilities to develop and manage the information services already discussed.
Also in the business environment we know that people and information are spread out and mobile. Therefore there is a need for a phone book, a directory. This is provided to the tools, utilities and services through the directory services in the reference model.
Finally the business environment must be secure, is mobile, must perform to meet the business needs, and must be manageable. This is depicted by the associated qualities that the reference model must support.
Again this reference model is focused on only those tools, utilities and services that develop, manage, or provide access to integrated information. It assumes an underlying technology platform of operating systems, networks, and middleware.
Information Provider
Manageability Policy
Performance Service Level
19 September 2018
(C) The Open Group 2003
(C) The Open Group 2002

11. Boundaryless Information Flow - Technical Taxonomy
19 September 2018
Boundaryless Information Flow - Technical Taxonomy
Qualities
Security Policy
Mobility Policy
Application Platform
Information Consumer Applications
Development
Tools
Brokering Applications
Management
Utilities
The current view of the architecture reference model for Boundaryless Information Flow is depicted here. This picture was derived from the business issues already presented.
First we understand that there are human and computing actors in the business environment that need information. These are information consumers. Second we understand that there are human and computing actors that have information and these are called information providers. Information consumers need technology services to help them request information. Information providers need services to help them liberate the information in their control. Thus information consumer services and information provider services.
Additionally we have established that there are numerous types of information consumer and information provider, much like in the stock market industry where brokers serve the purpose of helping information consumers get access to all the information they need from all the different information providers. This we have Brokering services in the reference model.
Additionally in the business environment we understand there are development organizations, outsourced or in-house, and there are management organizations. These organizations are supported by tools and utilities to develop and manage the information services already discussed.
Also in the business environment we know that people and information are spread out and mobile. Therefore there is a need for a phone book, a directory. This is provided to the tools, utilities and services through the directory services in the reference model.
Finally the business environment must be secure, is mobile, must perform to meet the business needs, and must be manageable. This is depicted by the associated qualities that the reference model must support.
Again this reference model is focused on only those tools, utilities and services that develop, manage, or provide access to integrated information. It assumes an underlying technology platform of operating systems, networks, and middleware.
Information Provider Applications
Manageability Policy
Performance SLAs
19 September 2018
(C) The Open Group 2003
Classes of Interfaces - formats and protocols …
(C) The Open Group 2002

12. A Level 2 Model Security Mobility Manageability Performance
19 September 2018
A Level 2 Model
Qualities
Security
Mobility
Application Platform
Information Consumer Applications
Web Portal
Desktop Video Conference
Streaming audio / video
information Access
Mail
Phone / Fax
Directory
Referencing/Dereferencing
Naming
Registration
Publish
Subscribe
Discovery
Application Message Format
Presentation
Transformation
Browser services
Portal and personalization
Meta indices
Application Messaging
Languages Libraries
Registries
Application to application communications services
Enterprise Appl Integration
Development Tools
Brokering Applications
Management Utilities
Monitors
Executory Utilities
Copy Managers
Business modeling tools
Design tools
Construction tools
Languages and Libraries
Information Brokers
Application Integrators
Not to complicate things, but there are further detailed views that need be exposed and models such as this one provide a little more detail that the level 1 diagram. This is the diagram that needs to be fully populated with the right things. Right now this is just been populated for demonstration purposes where it shows the level of detail we need to get to.
Digital Signature
Intrusion Detection
Key Management
Firewall
Encryption
AAAC
SSO
Info Format
eForm services
Instant messaging services
Information Access
Transformation Mapping
Query distribution
Aggregation
Search
File services
Web services
Web Portal
Information Provider Applications
Desktop Video Conference
Streaming audio / video
information Access
Mail
Phone / Fax
Messaging/Event Brokering
Process/Workflow Control
Manageability
Performance
19 September 2018
(C) The Open Group 2003
(C) The Open Group 2002

13. The Open Group Environment
Project Partners
Vendors
Government
Consortia & Associations
STRATEGY
MANAGEMENT
INNOVATION
STANDARDS
TESTING
CERTIFICATION
Tools
Vendors
Academics &
Researchers
Integrators &
Consultants
Systems &
Solutions Vendors
IT Customers
MEMBERS
19 September 2018
(C) The Open Group 2003

14. Member work areas Workflow Mgmt. Messaging Mobility Security Directory
Boundaryless
Information Flow
Reference Architecture
Architecture Forum
Workflow
Mgmt.
Messaging
Mobility
Security
Directory
System Mgmt.
Information
Mgmt.
User
Interface & Ontology
Transaction
Mgmt.
Enterprise Management Forum
Messaging
Security Forum
Directory Interoperability Forum
Mobile Management Forum
Service – QoS Task Force
Consistent Performance – RealTime & Embedded Systems
19 September 2018
(C) The Open Group 2003

15. Architecture forum membership
Architecting-the Enterprise Limited (UK)
BMC Software Inc. (US)
Booz Allen & Hamilton (US)
Boeing Corporation (US)
Brandeis University (US)
C and C Technology (UK)
Capital Health Authority (Canada)
CC and C Solutions ((Australia)
Centre For Open Systems (Aus)
ChiSurf (Hong Kong)
Computacenter (UK)
Computas (Nor)
Computer Associates (US)
Conclusive Logic (US)
Department of Defense / DISA (US)
Department of Works and Pensions (UK)
Desktop Management Task Force (US)
Frietuna Consultants (UK)
Fujitsu (Japan)
Hewlett-Packard (US)
Hitachi (Japan)
IBM (US)
Innenministerium NordRhein-Westfalen (Ger)
Jet Propulsion Labs (US)
Lockheed Martin (US)
MEGA International (Fra)
Ministry of Defence (UK)
MITRE Corporation (US)
Monash University (Australia)
NASA Goddard Space Flight Center (US)
National Computerization Agency (Korea)
NATO C3 Agency (Bel)
NEC (Japan)
NEMMCO (Australia)
NeTraverse, Inc. (US)
Nexor, Inc. (US)
Open GIS Consortium, Inc. (US)
PASS Network Consulting (Ger)
Popkin Software & Systems, Inc. (UK)
POSC (US)
Predictive Systems AG (Ger)
Primeur (Italy)
ReGIS (Japan)
QA Consulting (UK)
SCO (US)
Sun Microsystems (US)
Teamcall (Bel)
Telemanagement Forum (US)
Tivoli (US)
Toyota InfoTechnology Center (Japan)
US Army Weapon Systems Technical Working Group (WSTAWG)
Veriserve Corporation (US)
Westpac Banking Corporation (Australia)
TRON Association (Japan)
University of Plymouth (UK)
University of Reading (UK)
Visa International (US)
Weblayers, Inc. (US)
19 September 2018
(C) The Open Group 2003

16. Architects of The Open Group
19 September 2018
Architects of The Open Group
Asia
USA
Australia
Why these organizations participate:
Large/ Small/ Medium IT Customers – to reduce time, cost and risk in:
Developing technical and/or enterprise architectures
Procuring effective architecture tools
Procuring products to implement an architecture
Tools Vendors to learn about their potential customers requirements for both functionality and standardization
Large & Small Integrators/ Consultancies – discuss how to improve the efficiency and the quality of the end result of the Architecting process
Academic/ Research Organizations – demonstrate a ready route to industry standardization and market adoption for specific research technologies related to IT architecture. EU
19 September 2018
(C) The Open Group 2003
(C) The Open Group 2002

17. Architects of The Open Group
19 September 2018
Architects of The Open Group
Academic/
Research Organizations
Large IT Customers
Smaller Integrators/
Consultancies
Small IT Customers
Why these organizations participate:
Large/ Small/ Medium IT Customers – to reduce time, cost and risk in:
Developing technical and/or enterprise architectures
Procuring effective architecture tools
Procuring products to implement an architecture
Tools Vendors to learn about their potential customers requirements for both functionality and standardization
Large & Small Integrators/ Consultancies – discuss how to improve the efficiency and the quality of the end result of the Architecting process
Academic/ Research Organizations – demonstrate a ready route to industry standardization and market adoption for specific research technologies related to IT architecture.
Larger Integrators/
Consultancies
Tools Vendors
Systems/Solutions Vendors
19 September 2018
(C) The Open Group 2003
(C) The Open Group 2002

18. Architecture Forum The mission of the Forum’s members is to:
19 September 2018
Architecture Forum
The mission of the Forum’s members is to:
Advance the cause of IT Architecture - in order to
Improve the quality of information systems
To move IT Architecture from a cottage industry to a profession
Original (and continuing) focus: (TOGAF)
Industry consensus framework and method for IT architecture
Tool- and technology-neutral
Extended focus
Architecture Tools
IT Architect Certification
19 September 2018
(C) The Open Group 2003
(C) The Open Group 2002

19. What is an Architectural Framework?
19 September 2018
What is an Architectural Framework?
Architecture design is a complex process
An architectural framework is a tool for:
Designing a broad range of a architectures
Assisting the evaluation of different architectures
Selecting and building the right architecture for an organization
It embodies best practice and acknowledged wisdom
It presents a set of services, standards, design concepts, components and configurations
It guides the development of specific architectures
19 September 2018
(C) The Open Group 2003
(C) The Open Group 2002

20. Developing an IT Architecture
19 September 2018
Developing an IT Architecture
It is not possible for you to specify a single, universal architecture suitable for:
All purposes
At all times
An architecture must be suited to its specific business purpose
That purpose may change with time
19 September 2018
(C) The Open Group 2003
(C) The Open Group 2002

21. What is an Architectural Framework?
19 September 2018
What is an Architectural Framework?
Use of a framework leads to:
The use of common principles, assumptions and terminology
The development of information systems with better integration and interoperability, especially with respect to issues that affect the whole enterprise
WARNING!
A framework does not make architectural design an automatic process
It is a valuable aid to experienced and knowledgeable IT Architects
19 September 2018
(C) The Open Group 2003
(C) The Open Group 2002

22. Examples of Architectural Frameworks
Zachman Framework
DoD Architecture Framework – DoDAF
Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance – C4ISR
Federal Enterprise Architecture Framework - FEAF
Treasury Enterprise Architecture Framework - TEAF
These frameworks are all complementary to The Open Group Architecture Framework - TOGAF
TOGAF can be used in conjunction with these frameworks
19 September 2018
(C) The Open Group 2003

23. What is TOGAF? An architectural framework, not an architecture
19 September 2018
What is TOGAF?
An architectural framework, not an architecture
Vendor-neutral – developed by user consensus
It covers development of four types of architecture:
Business architecture
Data or information architecture
Application architecture
Technology architecture
All these are related
TOGAF 8 Enterprise Edition
TOGAF 7 Technical Edition
19 September 2018
(C) The Open Group 2003
(C) The Open Group 2002

24. 19 September 2018
TOGAF - Certification
TOGAF 7 is the vendor-neutral, global basis of Certification to impose standards within our profession
Architecture tools which support TOGAF 7
Training courses which instruct in TOGAF 7
Architects trained in the use of TOGAF 7
Professional services offered to support TOGAF 7
19 September 2018
(C) The Open Group 2003
(C) The Open Group 2002

25. TOGAF 8 Architecture Development Method Architecture Continuum
Organization Architectures
Architecture Development Method
Architecture Continuum
Common Systems Architectures
Foundation Architectures
Industry Architectures
Resource Base
19 September 2018
(C) The Open Group 2003

26. Architecture Continuum
Progressing toward your organizations enterprise architecture
Foundation
Architectures
Common Systems
Architectures
Industry
Architectures
Organisation
Architectures
19 September 2018
(C) The Open Group 2003

27. The Enterprise Continuum
Architecture Continuum
Foundation
Architectures
Common Systems
Architectures
Industry
Architectures
Organisation
Architectures
Guides &
Supports
Guides &
Supports
Guides &
Supports
Guides &
Supports
Products & Services
Systems Solutions
Industry
Solutions
Organisation
Solutions
Solutions Continuum
19 September 2018
(C) The Open Group 2003

28. Introduction to the TOGAF ADM
19 September 2018
Introduction to the TOGAF ADM
Guides an architect on how to:
Use reference models
Build an architecture or set of architectures
Adaptable to specific needs of a project
Iterative process - converges on an architecture responsive to the needs of the business
Enables the derived architecture to be frequently validated against the original motivation
19 September 2018
(C) The Open Group 2003
(C) The Open Group 2002

29. TOGAF 8 ADM Follow the phases of the ADM Results in
19 September 2018
TOGAF 8 ADM
Prelim: Framework and Principles
Follow the phases of the ADM
Results in
an organization-specific architecture
more reusable building block assets in the Architecture Continuum
Each iteration becomes easier and has more reusable building blocks to use
A Architecture Vision
H Architecture Change Management
B Business Architecture
Requirements
G Implementation Governance
C Information System Architectures
F Migration Planning
D Technology Architecture
E Opportunities and Solutions
19 September 2018
(C) The Open Group 2003
(C) The Open Group 2002

30. The TOGAF ADM - Architecture Vision
19 September 2018
The TOGAF ADM - Architecture Vision
Prelim: Framework and Principles
Use Business Scenarios
Understand how scenarios map to IT
Define relevant business requirements
Build consensus with business partners
Plan and get commitment to IT Governance
A Architecture Vision
H Architecture Change Management
B Business Architecture
Requirements
C Information System Architectures
G Implementation Governance
F Migration Planning
D Technology Architecture
E Opportunities and Solutions
19 September 2018
(C) The Open Group 2003
(C) The Open Group 2002

31. 19 September 2018
Business Scenarios
A complete description of the business problem in business and architectural terms
It ensures:
The architecture is based on a complete set of requirements
The business value of solving the problem is clear
The relevance of potential solutions is clear
Aids the buy-in by business stakeholders
Clarifies communication with vendors
Needs to be SMART
19 September 2018
(C) The Open Group 2003
(C) The Open Group 2002

32. A SMART Business Scenario
19 September 2018
A SMART Business Scenario
Specific - defines what needs to be done in the business
Measurable - clear metrics for success
Actionable - it clearly segments the problem and provides the basis for determining elements and plans for the solution
Realistic - the problem can be solved within the bounds of physical reality, time and cost constraints
Time-bound - there is a clear understanding of when the solution opportunity expires
19 September 2018
(C) The Open Group 2003
(C) The Open Group 2002

33. Contents of a Business Scenario
19 September 2018
Contents of a Business Scenario
Business Scenario problem description
Purpose of the Business Scenario
Detailed objectives
Environment and process models
Process description
Process steps mapped to environment
Process steps mapped to people
Information flow
The documentation of a Business Scenario should contain all the important details about the scenario. It should capture and sequence the critical steps and interactions between actors that address the situation. It should also declare all the relevant information about all actors, specifically: the different responsibilities of the actors; the key pre-conditions that have to be met prior to proper system functionality; and the technical requirements for the service to be of acceptable quality.
There are two main types on content: graphics (models), and descriptive text. Both have a part to play.
Business Scenario models capture business and technology views in a graphical form, to aid comprehension. Specifically, they relate actors and interactions, and give a starting point to confirm specific requirements.
Business Scenario descriptions capture details in a textual form.
19 September 2018
(C) The Open Group 2003
(C) The Open Group 2002

34. Contents of a Business Scenario
19 September 2018
Contents of a Business Scenario
Actors and their roles and responsibilities
Human actors and roles
Computer actors and roles
Requirements
Resulting technology architecture model
Constraints
IT principles
Technology architecture supporting the process
Requirements mapped to technology architecture
It is important to realize that the creation of a Business Scenario is not solely the province of the Architect. As mentioned previously, business line management and other stakeholders in the enterprise are involved, to ensure that the business goals are accurately captured. In addition, depending on the relationship that an organization has with its IT vendors, the latter also may be involved, to ensure that the roles of technical solutions are also accurately captured, and to ensure communication with the vendors.
Typically, the involvement of the business management is greatest in the early stages, while the business problems are being explored and captured, while the involvement of the architect is greatest in the later stages, when architectural solutions are being described. Similarly, if vendors are involved in the Business Scenario process, the involvement of the customer side (business management plus enterprise architects) is greatest in the early stages, while that of the vendors is greatest in the later stages, when the role of specific technical solutions is being explored and captured
19 September 2018
(C) The Open Group 2003
(C) The Open Group 2002

35. Phases used in a Business Scenario development
Gather information
Workshops are a great way to gather information through questions
Additional information such as strategies, plans, facts are solicited
Analyze and process information
Information is usually processed offline
Use a small team, your architects
Document information
Create models of your findings, both business and technical views
Augment models with detailed documentation
Review
Vet the models and documentation back to suppliers
Have a controlled review, allocate specific review sections to specific reviewers
Only a few reviewers needed to review the complete Business Scenario
19 September 2018
(C) The Open Group 2003

36. How? TOGAF Business Scenario Method
19 September 2018
How? TOGAF Business Scenario Method
Boundaryless
Liberate the data
Integrate data
Securely deliver data
Register data
Enable the flow of data
Develop
Manage
Adhere to policies
1 - problem
2 - environment
3 - objectives
4 - human actors
After
completion
the scenario is
basis and yardstick of future
work, (eg detailed architecture)
of communicating with procurement,
and of vendors’ implementation plans
1.        Identify, document and prioritize the problems that are driving the Scenario.
2.        Identify the environment and document it in the Scenario model.
3.        Identify and document the desired objectives of the Business Scenario.
4.        Identify human actors and their place in the Business Scenario.
5.        Identify computer actors and their place in the Technology model.
6.        Identify and document roles, responsibilities and measures of success per actor.
7.        Check for “fitness for purpose” and refine only if necessary.
5 - computer actors
6 - roles & responsibilities
7 - refine
19 September 2018
(C) The Open Group 2003
(C) The Open Group 2002

37. A complete picture Priorities Management Support Technical Trade-offs
19 September 2018
A complete picture
                              
Management
Support
Priorities
INTEROP
Technical
Stakeholder
Buy-in
Trade-offs
INTEGRATE
A Business Scenario is essentially a complete description of a business problem, both in business and in architectural terms, which enables individual requirements to be viewed in relation to one another in the context of the overall problem. Without such a complete description to serve as context:
There is a danger of the architecture being based on an incomplete set of requirements that do not add up to a whole problem description, and that can therefore misguide architecture work.
The business value of solving the problem is unclear
The relevance of potential solutions is unclear
Also, because the technique requires the involvement of business line management and other stakeholders at an early stage in the architecture project, it also plays an important role in gaining the buy-in of these key personnel to the overall project and its end-product - the IT architecture.
An additional advantage of Business Scenarios is in communication with vendors. Most architectures nowadays are implemented by making maximum use of commercial off-the-shelf software (COTS) solutions, often from multiple vendors, procured in the open market. The use of Business Scenarios by an IT customer can be an important aid to IT vendors in delivering appropriate solutions. Vendors need to ensure that their solution components add value to an open solution and are marketable. Business Scenarios provide a language with which the vendor community can link customer problems and technical solutions. Besides making obvious what is needed, and why, they allow vendors to solve problems optimally, using open standards and leveraging each other's skills.
problem
environment
objectives
human actors
comp. actors
roles&resp.
refine
Business
INFORM
Vendor
Understanding
19 September 2018
(C) The Open Group 2003
(C) The Open Group 2002

38. The TOGAF ADM - Business Architecture
19 September 2018
The TOGAF ADM - Business Architecture
Prelim: Framework and Principles
Create business baseline
Inventory of re-usable IT building blocks
Create target business architecture
Business View
Functional view
Platforms in place
Complete yet fit for purpose
Conduct gap analysis
Multiple views
A Architecture Vision
H Architecture Change Management
B Business Architecture
Requirements
C Information System Architectures
G Implementation Governance
F Migration Planning
D Technology Architecture
E Opportunities and Solutions
19 September 2018
(C) The Open Group 2003
(C) The Open Group 2002

39. TRM of Services and Qualities
19 September 2018
TRM of Services and Qualities
Qualities
Infrastructure Applications
Business Applications
Application Programming Interface
Software Engineering
Security
System & Network
Management
Processing
Transaction
Location & Directory
User Interface
Operations
International
Data Interchange
Data Management
Graphics & Image
Operating System Services
Network Services
Communications Infrastructure Interface
Communication Infrastructure
19 September 2018
(C) The Open Group 2003
(C) The Open Group 2002

40. What’s in a TRM? Qualities Communication Infrastructure
19 September 2018
What’s in a TRM?
Qualities
Operating System Services
Operating system services are responsible for the management of platform resources, including the processor, memory, files, and input and output. They generally shield applications from the implementation details of the machine. Operating system services include:
Kernel operations provide low-level services necessary to:
create and manage processes and threads of execution
execute programs
define and communicate asynchronous events …
Command interpreter and utility services include mechanisms for services at the operator level, such as:
comparing, printing, and displaying file contents
editing files
searching patterns
evaluating expressions ….
Batch processing services support the capability to queue work (jobs) and manage the sequencing of processing based on job control commands and lists of data. These services also include support for the management of the output of batch processing, which frequently includes updated files or databases and information products such as printed reports or electronic documents. Batch processing is performed asynchronously from the user requesting the job.
File and directory synchronization services allow local and remote copies of files and directories to be made identical. Synchronization services are usually used to update files after periods of off line working on a portable system.
Infrastructure Applications
Business Applications
Application Programming Interface
Software Engineering
Security
System & Network
Management
Processing
Transaction
Location & Directory
User Interface
Operations
International
Data Interchange
Data Management
Graphics & Image
Operating System Services
Network Services
Communications Infrastructure Interface
Operating System Services
Communication Infrastructure
19 September 2018
(C) The Open Group 2003
(C) The Open Group 2002

41. Standards Information Base (SIB)
19 September 2018
Standards Information Base (SIB)
A database of open industry standards with links to conformant products
Publicly available At
With user guide
Search or full listing
Can be used to:
Define particular services
Define properties of components
Be the basis of procurement procedures
Keeps the architecture up to date with the latest IT industry consensus
19 September 2018
(C) The Open Group 2003
(C) The Open Group 2002

42. What architects have said about TOGAF
19 September 2018
What architects have said about TOGAF
Shared best practice
Cuts up-front costs - eliminates re-invention of wheel
Corporate memory of previous successes and failures
Access to accumulated best practice wisdom
Comprehensive
Business requirements to solutions
Facilitates team communication
Refined and honed checklists at all levels
An open professional approach developed by professionals
The result of 8 years of global development
Vendor and technology neutral
19 September 2018
(C) The Open Group 2003
(C) The Open Group 2002

43. Next steps Download the TOGAF documentation Use Business Scenarios
Use Business Scenarios
The Interoperable Enterprise
The Executive on the Move
Identity Management
Run your own a 1 day Business Scenario workshop with your stakeholders
19 September 2018
(C) The Open Group 2003

44. Summary
Boundaryless Information Flow is critical in today’s business environment
Good professional architecture is a key enabler of Boundaryless Information Flow
TOGAF is an enabler of good professional architecture and is free for own use
Business Scenarios give a complete picture of the requirements
The Architecture Development Method provides a rigorous process and can be used with other frameworks
19 September 2018
(C) The Open Group 2003

45. Final thoughts Senior management buy-in is critical
TOGAF can be used to communicate with senior management about solving their Boundaryless Information Flow problem
Try it!
19 September 2018
(C) The Open Group 2003

46. Contact Information
Thank you very much
Allen Brown
President & CEO
44 Montgomery Street
Suite 960
San Francisco, CA
94104 USA
Tel
19 September 2018
(C) The Open Group 2003