Boundaryless Information Flow The Role of Architecture
Upcoming SlideShare
Loading in...5
×
 

Boundaryless Information Flow The Role of Architecture

on

  • 1,049 views

 

Statistics

Views

Total Views
1,049
Views on SlideShare
1,049
Embed Views
0

Actions

Likes
2
Downloads
51
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • June 8, 2010 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
  • June 8, 2010
  • June 8, 2010 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.
  • 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.
  • June 8, 2010 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.
  • June 8, 2010 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.
  • June 8, 2010 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.
  • 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.
  • 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.
  • June 8, 2010
  • June 8, 2010
  • June 8, 2010
  • June 8, 2010
  • June 8, 2010
  • June 8, 2010
  • June 8, 2010
  • June 8, 2010 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.
  • June 8, 2010 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
  • June 8, 2010 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.
  • 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.
  • June 8, 2010
  • June 8, 2010

Boundaryless Information Flow The Role of Architecture Boundaryless Information Flow The Role of Architecture Presentation Transcript

  • Boundaryless Information Flow The Role of Architecture Allen Brown President & CEO [email_address] 44 Montgomery Street Suite 960 San Francisco, CA 94104 USA Tel +1 415 374 8280 www.opengroup.org
  • 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
  • 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. ”
    Source: “The Interoperable Enterprise” http://www.opengroup.org/cio/iop/index.htm
  • A common problem Buy Space Internal Space Sell Space Procuring Manufacturing Legal Finance Assembling Customer Support Selling Procurement Systems Design Systems Online Systems ERP Systems Requirements Systems Systems
    • The cause :
    • multiple systems, conceived and developed individually
    • Compounding the problem :
    • cross-functional teams continuously forming, new business partners, stove-piped information
    Partner 1 Partner 2 Partner 3000 Appl 1 Appl 2 Appl 50 Appl 1 Appl 2 Appl 50 Appl 1 Appl 2 Appl 50
  • 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. Vision
  • Boundaryless Information Flow … Buy Space Internal Space Sell Space Procuring Manufacturing Legal Finance Assembling Customer Support Selling Procurement Systems Design Systems Online Systems ERP Systems Requirements Systems Systems Processes … needs access to information that was not necessarily designed to leave its original domain.
  • 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
  • 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
  • Architecture role in the life-cycle
    • document current situation
    • capture business requirements
    • prioritize
    • communicate
    technical needs criteria for product selection assess trade-offs/priorities communicate gain early user buy-in manage expectations communicate guide procurement, development and integration control design changes system integrity communicate relationships and dependencies recall trade-offs & rationale communicate sound basis SMART objectives communicate Plan Design Build Roll-out Maintain Post Review
  • Boundaryless Information Flow - Business Taxonomy
    • Mobility Policy
    Phone Books/Directories Information Provider Management Organization Brokers Development Organization Information Consumers Performance Service Level Manageability Policy Security Policy
  • Boundaryless Information Flow - Technical Taxonomy
    • Mobility Policy
    Qualities Qualities Application Platform Classes of Interfaces - formats and protocols … Information Provider Applications Management Utilities Brokering Applications Development Tools Information Consumer Applications Performance SLAs Manageability Policy Security Policy
  • A Level 2 Model Qualities Qualities Application Platform Information Provider Applications Management Utilities Brokering Applications Development Tools Information Consumer Applications Desktop Video Conference information Access Streaming audio / video Mail Phone / Fax Web Portal Business modeling tools Design tools Construction tools Languages and Libraries Monitors Executory Utilities Copy Managers Mobility Performance Manageability Security Information Brokers Application Integrators Desktop Video Conference information Access Streaming audio / video Mail Phone / Fax Web Portal Application to application communications services Directory Referencing/Dereferencing Naming Registration Publish Subscribe Discovery Digital Signature Intrusion Detection Key Management Firewall Encryption AAAC SSO Presentation Transformation Browser services Portal and personalization Meta indices Information Access Transformation Mapping Query distribution Aggregation Search File services Web services Application Messaging Languages Libraries Registries Application Message Format Info Format eForm services Instant messaging services Messaging/Event Brokering Process/Workflow Control Enterprise Appl Integration
  • The Open Group Environment Tools Vendors Academics & Researchers Integrators & Consultants Systems & Solutions Vendors IT Customers MEMBERS Project Partners Vendors Government Consortia & Associations STRATEGY MANAGEMENT INNOVATION STANDARDS TESTING CERTIFICATION
  • Member work areas Boundaryless Information Flow Reference Architecture Security Forum Mobile Management Forum Enterprise Management Forum Messaging Directory Interoperability Forum Architecture Forum Directory Security System Mgmt. Information Mgmt. Messaging Workflow Mgmt. Mobility User Interface & Ontology Transaction Mgmt. Consistent Performance – RealTime & Embedded Systems Service – QoS Task Force
  • Architecture forum membership 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) 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) 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)
  • Architects of The Open Group Asia Australia EU USA
  • Architects of The Open Group Large IT Customers Small IT Customers Tools Vendors Systems/Solutions Vendors Larger Integrators/ Consultancies Smaller Integrators/ Consultancies Academic/ Research Organizations
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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 7 Technical Edition TOGAF 8 Enterprise Edition
  • 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
  • TOGAF 8 Industry Architectures Common Systems Architectures Foundation Architectures Architecture Development Method Resource Base Organization Architectures Architecture Continuum
  • Architecture Continuum
    • Progressing toward your organizations enterprise architecture
    Foundation Architectures Common Systems Architectures Industry Architectures Organisation Architectures
  • The Enterprise Continuum Foundation Architectures Common Systems Architectures Industry Architectures Organisation Architectures Systems Solutions Industry Solutions Organisation Solutions Products & Services Solutions Continuum Architecture Continuum Guides & Supports Guides & Supports Guides & Supports Guides & Supports
  • 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
  • TOGAF 8 ADM
    • 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 Requirements B Business Architecture E Opportunities and Solutions F Migration Planning Prelim : Framework and Principles D Technology Architecture G Implementation Governance C Information System Architectures
  • The TOGAF ADM - Architecture Vision
    • 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 G Implementation Governance C Information System Architectures Requirements B Business Architecture E Opportunities and Solutions F Migration Planning Prelim : Framework and Principles D Technology Architecture
  • 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
  • A SMART Business Scenario
    • S pecific - defines what needs to be done in the business
    • M easurable - clear metrics for success
    • A ctionable - it clearly segments the problem and provides the basis for determining elements and plans for the solution
    • R ealistic - the problem can be solved within the bounds of physical reality, time and cost constraints
    • T ime-bound - there is a clear understanding of when the solution opportunity expires
  • 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
  • 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
  • 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
  • How? TOGAF Business Scenario Method
    • 1 - problem
    2 - environment 3 - objectives 4 - human actors 5 - computer actors 6 - roles & responsibilities 7 - refine After completion the scenario is basis and yardstick of future work, (eg detailed architecture) of communicating with procurement, and of vendors’ implementation plans
    • Boundaryless
    • Liberate the data
    • Integrate data
    • Securely deliver data
    • Register data
    • Enable the flow of data
    • Develop
    • Manage
    • Adhere to policies
  • A complete picture Business Technical Priorities Trade-offs INTEROP INTEGRATE INFORM                                 problem environment objectives human actors comp. actors roles&resp. refine Management Support Stakeholder Buy-in Vendor Understanding
  • The TOGAF ADM - Business Architecture
    • 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 G Implementation Governance C Information System Architectures Requirements B Business Architecture E Opportunities and Solutions F Migration Planning Prelim : Framework and Principles D Technology Architecture
  • TRM of Services and Qualities Qualities Infrastructure Applications Business Applications Communication Infrastructure Communications Infrastructure Interface Network Services Operating System Services System & Network Management Software Engineering Application Programming Interface Data Management Location & Directory Data Interchange International Operations Transaction Processing Security Graphics & Image User Interface
  • What’s in a TRM? Qualities Infrastructure Applications Business Applications Communication Infrastructure Communications Infrastructure Interface Network Services System & Network Management Software Engineering Application Programming Interface Data Management Location & Directory Data Interchange International Operations Transaction Processing Security Graphics & Image User Interface Operating System Services Operating System Services
    • 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.
  • Standards Information Base (SIB)
    • A database of open industry standards with links to conformant products
    • Publicly available
      • At http://www. opengroup .org /sib
      • 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
  • 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
  • Next steps
    • Download the TOGAF documentation
      • http://www. opengroup .org/architecture/togaf7/index7. htm
      • http://www. opengroup .org/architecture/togaf8/index8. htm
    • 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
  • 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
  • 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!
  • Contact Information
    • Thank you very much
    Allen Brown President & CEO [email_address] 44 Montgomery Street Suite 960 San Francisco, CA 94104 USA Tel +1 415 374 8280 www.opengroup.org