Hi
Corporate Governance
But some articles about IT Governance
jueves, 28 de febrero de 2013
miércoles, 27 de febrero de 2013
domingo, 24 de febrero de 2013
sábado, 23 de febrero de 2013
viernes, 22 de febrero de 2013
jueves, 21 de febrero de 2013
miércoles, 20 de febrero de 2013
GRC Fundamentals - London UK February 2013
http://www.oceg.org/event/grc-fundamentals-london-uk-february-2013
GRC Fundamentals - London UK February 2013
TIMEZONE: (All day) (GM +00:00)
FROM: Wednesday February 06, 2013 (All day)
TO: Friday February 08, 2013 (All day)
London, UK
LONDON, UK
The GRC Fundamentals seminar will teach you how to efficiently design and enhance GRC activities within your business based on established GRC standards. This program also will prepare you to enhance your credentials by taking the GRC Professional certification exam, offered by OCEG's affiliate organisation, GRC Certify. The seminar fee includes the cost of the GRCP exam and one year of certification as well as a one year All Access Pass which you can use to obtain numerous GRC resources and continuing education credits.
Through lectures and practical group interaction, discussions, and exercises, you will learn about defining a GRC strategy; integrating and improving corporate performance, risk and compliance programs; strengthening core business processes; and improving use of technology to support the integrated governance,management and assurance of performance, risk and compliance. There simply is no other training program that provides you with the skills and resources you need to help your organisation improve its GRC capability by implementing the publicly vetted open source standards set out in OCEG’s GRC Capability Model.This course is suitable for executives, managers and key staff in all GRC roles (including risk, audit, compliance, legal, performance, and IT). Members of technology providers and professional service firms will also benefit from understanding the issues and approaches to GRC challenges faced by organizations they seek to serve.
You will learn how to:
- Develop a GRC strategic plan
- Align risk and compliance in context of the organisation
- Understand, define, and enhance organisational culture as it relates to performance, risk, and compliance
- Implement effective, efficient and agile GRC processes using the OCEG GRC Capability Model
- Motivate and inspire desired conduct through the concept of Principled Performance
- Understand technology’s role in GRC
- Develop ongoing monitoring and continuous improvement of GRC activities through metrics and measurement
Individual benefits
- Differentiate yourself from the competition
- Become a sought after expert in GRC and gain an advantage in the competitive job market
- Increase your potential earnings
- Become a recognised GRC Professional
- Receive a one year All Access Pass to OCEG resources
This course prepares you to sit the GRC Professional Certification exam offered by OCEG affiliate GRC Certify (www.grccertify.org). Cost of the exam and one year of certification is included in the seminar fee.
Organisational benefits
- Raise the GRC bar and boost stakeholder confidence
- Meet legal/regulatory compliance obligations effectively
- Improve responsiveness, efficiency and strategic business decisions
- Protect and enhance your brand and avoid fines, penalties and reputation damage
- Demonstrate GRC implementation, auditing and consulting expertise
- Differentiate from your market competitors
- Increase the value of your GRC consultants
At the heart of the seminar is the OCEG GRC Capability Model. Although various standards and frameworks exist to address discrete portions of governance, risk management and compliance issues, the OCEG GRC Capability Model is the only open standard that provides comprehensive and detailed practices for an integrated GRC program.
Organizations can use the GRC Capability Model to address a broad GRC program across the organization or develop a structure within domains of GRC (e.g., legal, compliance, risk management, audit). The goal is to make GRC processes more effective, efficient, and agile to the needs of the business.
This is a basic course and there are no prerequisites or advanced preparation.
martes, 19 de febrero de 2013
A Pragmatic Approach to Enterprise Architecture
hi
http://www.sys-con.com/node/2529249
Managing complexity is difficult in any growing business. As companies innovate, add new business lines, expand their global reach, cater to increased volume, or adopt new regulatory rules, processes proliferate and the discipline surrounding them goes out of the window. Moreover, the IT that supports these processes becomes more entangled as aging legacy applications jostle with new applications to support the needs of the business. Over time the technology that support this business unravels, causing the environment to suffer from instability and poor performance and become difficult to change and maintain. In short, it lowers business efficiency and effectiveness.
A sound Enterprise Architecture (EA) approach is required to ensure that both the business and technology are well aligned and will help restore order to this landscape. An Enterprise Architecture is a description of the goals of a company, how these goals are realized by business processes, and how these business processes can be better served through technology. EA is about finding opportunities to use technology to add business value.
The primary purpose of an EA is to inform, guide, and constrain the decisions for the enterprise, especially those related to IT investments. The true challenge of EA is to maintain the architecture as a primary authoritative resource for enterprise IT planning. This goal is not met via enforced policy, but by the value and utility of the information provided by the EA.
Why Have an EA Approach:
- Provides a basic framework for major change initiatives
- Divides and conquers technical and organizational complexities
- Supports business and IT budget prioritization
- Improves the ability to share and efficiently process information
- Provides the ability to respond faster to changes in technology and business needs
- Reduces costs due to economies of scale and resource sharing
- Enhances productivity, flexibility and maintainability
- Serves as a construction blueprint and ensures consistency across systems
- Supports decision making
More specific benefits include:
- Simplified application development
- Quality
- Integration
- Extensibility
- Location transparency
- Horizontal scaling
- Isolation
- Portability
- Reuse
An EA is a blueprint that is developed, implemented, maintained, and used to explain and guide how an organization's applications landscape works together to efficiently accomplish the mission of the organization. An EA addresses the following views:
- Business activities and processes
- Data sets and information flows
- Applications and software
- Technology
The Four Pillars of Enterprise Architecture:
1. Business Architecture
Business Architecture realizes the business strategy. It describes how we organize our business processing to meet the strategic needs of the business. It should allow us to maximize the flexibility of the business to respond to changing business environments, reduce the complexity of our environment by simplifying business processing and reduce the effort required for application implementation and maintenance. It provides a view of the business and describes where we can improve business functions.
Examples:
- Create processing utilities for common functions within the back office area that support cross products such as confirmations, cash settlement, security settlement, and collateral management
- Create a single common analytics versus an individual analytics library used for pricing products. Common analytics can be used for all front office trading desks, for different functions such as front office and risk
2. Data Architecture
The data architecture describes the way data will be processed, stored and used by the organization. It lays out the criteria on processing operations including the whole flow of the system. It should increase the accuracy and timeliness of business data used by applications.
An example of patterns used is Master Data Management (MDM) - its objective is to provide processes for collecting, aggregating, quality-assuring, persisting and distributing such data throughout an organization to ensure consistency and control in the on-going maintenance and application of this information. Moving to a model of a single golden data source will eliminate duplication and inefficiency, e.g., single bond static data sourced from multiple data vendors and publishing it to multiple systems (e-trading, trading, risk and PL, and settlement systems.)
Implement a firm-wide description of common data objects, e.g., fpML (open standard XML standard for electronic dealing and OTC derivatives processing). This will reduce the risk of the data being misunderstood and provide a higher quality of data flowing through the organization thereby increasing efficiency and effectiveness.
3. Applications architecture
Applications architecture describes the structure and behavior of applications used in a business, focusing on how they interact with each other and with users. It's focused on the data consumed and produced by applications rather than their internal structure.
Examples:
- Enforcing the use of a golden source of data, e.g., instrument static, counterparty static, market data, etc.
- Standardizing on an application platform and interfacing approach
- Implementing a standard application monitoring framework for all applications to report the business status
4. Technical Architecture
This describes the common technology components that will be used to build our applications. This includes standards for vendor packages, third-party products and application components, e.g., servers, networks, desktops, middleware, security, storage, and virtualization. This will describe the current and target state.
Examples:
- SSO should be a standard mechanism for user authentication for all enterprise applications
- Implement a server virtualization strategy to help reduce costs and increase flexibility
- All critical applications should have a recovery time of less than an hour
- Have a technology menu of strategic products that development teams can use for projects
Building an EA for Your Organization
It is important to understand the business strategy of the organization and this drives everything. This vision and strategy will drive where the organization's IT environment and capabilities should be in the next three years.
The next step in this process is to characterize the current status and snapshot the existing IT capabilities. The word "characterize" is used because it isn't usually necessary to identify and analyze everything IT or information related in the organization. You just need enough data to understand the basic situation you are in and the problems that exist, and to develop an idea of where you want to go. You need to understand where the inefficiencies and duplications exist. The question is whether IT is being used in the most effective way to accomplish the organization's program goals.
What Work Is Performed?
You must have a clear understanding of what work the organization performs and where it is performed (anywhere from one location to multiple locations throughout the world).
What Information Is Needed and by Whom?
You need to understand the basic flow of information, not just within your organization but also to and from your organization, and what the information consists of and how that information is organized.
What Applications Are Used to Process that Information?
What software is used to process, analyze, etc., the needed information? What types of data structures and protocols are used?
What Technology Is Used to Perform the Work?
What IT hardware infrastructure is currently used?
Having formed an understanding of where you currently stand, you now need to try to figure out where you need to be in the future. There are two main drivers for this:
- Business drivers tell you that you need to do business differently. Customers may be demanding better or different services.
- Technology drivers tell you that technology is providing you with options for doing things better
The target architecture is the heart of the process. The four components (business architecture, data architecture [e.g., data sets and information flows], application architecture and technical architecture) of the EA need to be modeled separately. Security considerations should be addressed throughout. The process consists of defining each set of architectural components and its key attributes. The result is an organized set of definitions and models to reflect the different views of the architecture. Again, the relative complexity of the situation will determine how detailed and extensive this effort and documentation needs to be. The four components are then synthesized into a comprehensive target architecture.
Due to the rapid pace of technology advancement, the goal should be to produce an "evolvable" architecture that can accommodate change easily. Some rules to help to produce this are - keep things modular and loosely coupled, have well-defined boundaries between systems and components, reusable logic should be divided into services, use industry-standard interfaces, use open-systems standards, and use common mechanisms whenever possible. Planning for loosely coupled, modular systems with clear boundaries allows you to change portions of the IT architecture without having to revise other aspects in the architecture, and also helps you see how changes in one part of the architecture may affect other elements.
At this point, you are in a position to determine the gaps between your current and target architectures. What are the differences between your baseline and the architecture you want to achieve?
Architecture Governance
For architecture to succeed within an organization, it is essential to have the support and commitment of senior management. This major initiative needs sponsorship by the CIO, and senior management need to be supportive and fully involved in ensuring it is a success. The governance process needs to ensure that:
- People planning and developing IT systems do so in a way consistent with the target architecture
- Procurements are consistent with the target architecture
- Determine if exceptions or changes to the Enterprise Architecture are needed for a specific system or procurement
- Track the implementation of the architecture migration plan and the benefits/flaws of the Enterprise Architecture
- Keep the EA up-to-date, thereby reflecting changes in the business, new technology, etc.
There needs to be integration with the program planning and the budget processes.
Technology is changing rapidly and business needs and processes change over time. Therefore, the target architecture, whether fully implemented or not, that addresses how IT and information will serve business needs must be periodically reviewed and updated to reflect these changes.
It is important that EA is not used as a mechanism that attempts to slow down delivery unnecessarily; it needs to add value to the business by producing superior solutions and not add unnecessary bureaucracy. A pragmatic approach to architecture is needed that balances the needs for agility and innovation yet delivers the efficiency and effectiveness in the technology solution provided by EA.
Architecture Principles
Architecture principles define the fundamental assumptions and rules of conduct for the IT organization to create and maintain IT capability. It provides a compass to guide it to its target architecture. A well-defined architecture principle consists of a name, definition, motivation and implications. Table 1 shows the Architecture Principles on the Reuse, Buy, Build Principle.
Table 1: Reuse, Buy, Build Principle
Definition
(What)
We prefer to reuse existing assets over buying, and buying over building
Motivation
(Why)
We are not a software company
Our company has many IT assets that are underleveraged because we have previously favored building rather than reusing or buying
We have many redundant applications and reducing this through reuse will reduce maintenance costs and improve system stability
Implications
(How)
Architecture Governance will ensure projects adhere to this principle.
Our company will develop an understanding of functional and technical assets available for reuse. This will be kept up to date.
We will strive for fewer and deeper software vendor relationships and need to influence their roadmaps to mesh with our needs
To add a new tool to our portfolio, we will also plan and fund replacement of the installed base of the former tool
Architecture principles become a core shared assumption for all initiatives in the enterprise. This radically simplifies decision making. It ensures that all projects align with and are moving toward the target state
Other enterprise architecture principles an organization might consider include:
- Don't Automate Bad Business Complexity Principle
- Avoid Package Customization Principle
- Prefer Service Orientation over Application Orientation Principle
- Don't Over / Under Engineer Principle
An example of the Banking Specific Architecture Principle:
- Only a master source of data can create business events
- All processing should be STP with manual interventions only for exceptions
- Combine multiple analytics libraries into a single common library (depends on trading desk size and product complexity!)
Conclusion
EA is important and without it organizations will be unable to deliver technology in an efficient and effective manner. If a project team works anyway they want to, and use any technology they want to, chaos will result. Functionality and information will be duplicated and reuse will occur sporadically, if at all. There will be conflict between systems that cause each other to fail. Individual projects may be deemed successful, but as a portfolio there may be serious challenges. Systems don't exist in vacuum, but rather co-exist with several and sometimes hundreds of other systems. For example, building a Bloomberg interface to store bond static and prices built by the rates front office IT group may be viewed as a success in isolation, but such functionality are required by many systems within the organization, e.g., e-trading, pricing analytics, risk, settlement systems, and other front office trading applications, e.g., credit derivatives and repo. If each area builds such functionality, costs skyrocket (e.g., multiple Bloomberg licenses, duplication of interfaces, data, hardware), and it increases complexity and operational risk within the organization. EA plays a fundamental role in preventing such scenarios from occurring.
Published February 7, 2013 – Reads 1,598
Copyright © 2013 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.
A Pathway to Principled Performance®: The OCEG Framework Approach to Integrated GRC
Hi
http://www.oceg.org/view/20055
There is a battle raging in the corporate community. It pits traditional views against modern thinking and old ways of doing business against new, post-SOX attitudes and practices. It cuts to the heart of why and how companies do what they do. It involves the most basic motivations and rewards for corporate activity. It’s a battle that is critical to the future of business as we know it, one that needn’t take place at all.
The choices the battle would have corporate executives make are based on false distinctions: differences that disappear when those executives take the big-picture approach to governance, risk management, compliance and internal control that emphasizes an integrated approach to what OCEG calls “Principled Performance.”
On one side is the classic view of enterprise, that an organization is accountable to its shareholders and, as a proxy for the public, to the government, but to no one else. As long as it follows applicable laws and regulations, the classic thinking goes, the organization should be able to pursue any objectives and engage in any activity that delivers value to its shareholders.
Facing off against the classic view is the broader view, that an organization is accountable to an expanding universe of stakeholders that includes not just shareholders and the government, but the public, NGOs, media and, increasingly, the environment. This approach is typified by triple-bottom-line reporting and the rise of corporate social responsibility and its cousins, socially responsible investing and sustainability.
Never the twain shall meet, right? Wrong. Draw up the paperwork for a permanent peace in this conflict, because the idea that an organization must choose one approach over the other is based on a false premise. Sensible executives will pursue the path of Principled Performance and not waste their time making a choice they don’t need to make.
Principled Performance is not just ethical performance, economic performance or corporate social responsibility. It is the clear articulation of an enterprise’s objectives, both financial and nonfinancial, and the methods by which it establishes and stays within the boundaries it will observe while driving toward those objectives.
The boundaries that guide a company’s operations may be mandated by the laws, rules, regulations and other requirements imposed on the organizations or by or voluntary boundaries, including its core values, internal policies and external promises. Understand that those boundaries exist right now. What changes with a Principled Performance approach is that an organization actively defines the boundaries and actively considers them in determining its path to achieving organizational objectives.
Principled Performance is a management discipline that provides flexibility in defining the objectives an organization will pursue, beyond compliance with mandates, and how it pursues them. What is most important for Principled Performance is that an organization:
- clearly defines its principles;
- defines what it seeks to achieve;
- defines how it will achieve these objectives;
- specifically defines how it will address risks and uncertainty, protect value and stay within defined boundaries of conduct along the way;
- makes these choices transparent for internal and external stakeholders; and\does all of this using an integrated approach where the “what’s” and “how’s” are continuously improved for the highest level of performance.
Principled Performance simply means defining “right” for your company, then doing the “right” things the “right” way; not only to create value, as in the traditional view, but to protect value, as well, and to address uncertainty and help the organization stay within its customized boundaries of conduct.
Principled Performance is about enhancing the traditional shareholder view of financial performance to include desired outcomes that are not directly or exclusively financial, but that address other stakeholder interests that secure long-term success. Principled Performance is about how an organization pursues those outcomes: the inputs, the processes and the outputs.
Integrated Governance, Risk Management and Compliance (GRC)
There are a number of enterprise processes that help organizations drive Principled Performance. Recently, and with a boost from the OCEG community, executives from various industries have realized that they’re not alone in seeking an integrated approach and the focus on Principled Performance it permits. When the conversations began, they found that much of their work was fundamentally aimed at similar goals and was conducted using a similar set of processes. In fact, recent OCEG research indicates that more than 90 percent believe that common processes should be harmonized and standardized across governance, risk management, compliance and internal control systems throughout the enterprise.
And yet, historically, few executives from those different departments, or their staffs, interacted regularly with each other. Each generally remained in his own functional silo, dealing with his own issues. Each generally used a different vocabulary and different processes to accomplish similar objectives. To the extent that technology was used, it too was siloed. The opportunity to unlock value and reduce costs through integration and standardization of those processes was unrealized.
Together with OCEG, many of those executives have begun to pursue opportunities for integration. GRC has become the shorthand used to reference such integration, but the more you try to define the G, R and C, the more confusing the issue becomes. Step back and see the three functions as interrelated processes designed to keep the company on course as it drives toward its objectives and the picture is clearer. Integrated GRC provides a pathway to Principled Performance.
A Meta-Framework
The OCEG approach to Principled Performance is encompassed within the OCEG Framework, a kind of “meta-framework” that facilitates GRC integration. Incorporating the most current thinking and existing best practices from the relevant disciplines, and frameworks that apply them, it provides both a process model and key guidance on GRC issues that arise in most organizations.
At the heart of the OCEG Framework is the GRC 360 Capability Model, commonly referred to as the Red Book. It provides general guidance about the people, processes and technology that should be in place to enable integrated GRC. The Red Book can be applied to the entire enterprise or to a particular department or risk area.
When an organization uses the Red Book, it not only addresses GRC from all angles, but also:
- breaks down departmental and professional silos that typically exist between various GRC areas;
- improves the overall effectiveness of every GRC process so that risks and requirements are appropriately addressed; and
- improves the overall performance of every GRC process so that the proper investment is made in each area and improves the return on investment in GRC.
Spelling It Out
There are more processes than governance, risk and compliance playing critical roles in GRC, but 13-letter acronyms rarely catch on. To understand the complete portfolio of processes related to GRC, consider the following areas:
1. Governance. Processes typically executed by the board, corporate secretary and governance professionals including board management, stakeholder relations, evaluating performance against enterprise objectives, vetting strategy, risk oversight and so forth.
2. Strategy. Processes typically executed by the chief executive officer, c-suite as a whole and strategy professionals including setting strategy, designing balanced scorecards, managing corporate performance and the like.
3. Risk Management. Processes typically executed by the chief risk officer, business line and other executives including: identifying, assessing and managing all types of risk (e.g. strategic risk, financial risk, operational risk, compliance risk).
4. Audit. Processes typically executed by the chief audit executive, internal audit, audit committee and external auditors including managing internal audits, facilitating external audits, executing financial reporting, evaluating internal controls over financial reporting and other risks, and conducting investigations.
5. Legal. Processes typically executed by the general counsel and legal staff such as defining legal strategy, investigations, litigation and assisting with due diligence for mergers and acquisitions.
6. Compliance. Processes typically executed by the general counsel, chief compliance and ethics officer, compliance and legal professionals including compliance in areas such as: employment, environmental, government contracts, global trade, anti-fraud, anti-corruption, information privacy and security, sales practices, advertising and marketing.
7. Information Technology. Processes typically executed by the chief information officer, privacy officer and/or security officer including automating controls, managing electronic records, facilitating internal and external reporting, delivering electronic filings, securing information and ensuring privacy.
8. Ethics and Corporate Social Responsibility. Processes typically executed by the chief ethics officer and chief responsibility officer including managing the code of conduct, developing ethical leaders, promoting adopted principles and values, crafting public communications and reports and aligning incentives and human behavior.
9. Quality Management. Processes typically executed by quality professionals throughout the organization such as integrating “lean” thinking, Six Sigma or other techniques into all enterprise processes and conducting root cause analysis and process improvement projects.
10. Human Capital and Culture. Processes typically executed by human resource professionals and organizational design and development professionals including enhancing workforce capabilities, appraising individual and team performance, developing culture of performance, integrity, openness and accountability.
Each of these plays a key role in helping an organization drive Principled Performance. All of them can benefit from a shared strategy and operational approach and from cross-communication and shared technology.
Common Elements
Think about what those who manage governance, risk, compliance, HR, IT and all the other capabilities essential to strong performance do and consider the fundamental processes that they execute. They all engage in the following elements of the GRC 360 Capability Model:
- Set Objectives. Understand the objectives that the organization is pursuing and set GRC objectives accordingly. Consider how GRC objectives can support organizational objectives.
- Identify Boundaries. Identify the boundaries of acceptable enterprise conduct. Mandated boundaries include laws, rules and regulations that the organization must follow. Voluntary boundaries include enterprise values, industry standards, voluntary commitments (such as sustainability and corporate social responsibility), brand, contractual obligations and internal policies.
- Assess Risks. Identify, analyze and prioritize the key event s that can catapult the organization beyond its current operating model and objectives or put the organization at risk of not achieving objectives or not staying within boundaries.
- “Proact.” Proactively put in place policies, procedures, controls , accountability, incentives and other structures that help the organization address risks and promote desirable conduct; prevent undesirable conduct; prepare the organization for when (not if) an adverse or opportunistic event occurs; and protect the organization from negative impact.
- Detect and Check. Use a series of “push” and “pull” mechanisms gathering information to detect problems and check for progress and performance. Examples include a whistleblower hotline (allow people to push information to management); workforce surveys and ethnography (allow management to pull information from people); control and trigger monitoring (allow systems to push information to management); and control assessment (allow management to pull information from systems).
- Respond. If a problem is discovered, respond and drive toward resolution. Some problems are more difficult than others and may require more time to solve. Some problems are more legally significant than others and may require special investigations. Root cause analysis is important so that the organization can treat the cause, not the symptoms, of a problem.
- Evaluate. Periodically evaluate whether the process is appropriately designed, operating as designed, and actually delivering envisioned outcomes to the business. This means not only evaluating “effectiveness” as defined by regulators, but also “performance,” which matters much more to shareholders and stakeholders.
- Improve. Based on the root causes of detected problems and the results of the overall evaluation of the process, take appropriate steps to improve the program so that similar problems and weaknesses are not repeated.
- Communicate. Throughout the process , communicate with all appropriate internal and external stakeholders. This means not only reporting to management and the board, but also to external stakeholders such as regulators, government and the community.
Again, each functional area deals with specific issues (e.g., employment compliance or information privacy risks), but the basic operating model is the same. Recognizing the many important similarities is the first step to unlocking cash and value. By harmonizing vocabulary, approach and processes, corporations can improve performance.
Integrate, Do not Consolidate
Integration does not mean consolidation. Rather, integration means applying a common vocabulary, approach and, ideally, technology infrastructure to GRC processes. That way, improvements in one GRC area can be replicated in other GRC areas across the enterprise. And perhaps most importantly, integration provides a single version of the truth, when senior executives and the board ask questions like: “What are the most important risks that we face?” and: “How do we know that the organization is operating within defined boundaries?”
Some organizations pursue what Forrester analyst Michael Rasmussen calls a “federated” model for integrated GRC, where key risks, policies and controls are maintained at the corporate level, while more detailed risks, policies and controls are managed at the business unit or functional level. Risks are considered as part of a total portfolio and are identified using a common approach. Whether centralized or decentralized, policies and controls use a consistent approach, common language and common technology to reduce confusion, conflict and costs.
Facing Challenges
While cost savings and performance improvements can be realized, there are challenges along the path of integrated GRC:
- People like their jobs. “Integration” and “process improvement” projects typically result in reductions or at least redeployment of human capital. For some, there will be either a reduction in staff or status in the organization.
- People like their silos. Breaking down silos introduces change management issues. Resistance to change will impede progress.
- People like their spreadsheets. New skills are required to perform to the “highest common denominator.” For example, in some GRC areas, the level of sophistication around evaluating performance may be extremely low. The goal of integrated GRC is to raise the level of competence across the board. Some individuals will make this transition; others will not.
- Insufficient outrage about what is not known. Sometimes, organizations need to hit rock-bottom before change is possible. Many organizations employ tremendous capital addressing GRC; however, few have full information about these costs - not only the costs of duplicated staff and duplicated technology - but also the costs of errors, sub-optimal performance and poor information quality.
Totally Revolutionary
Much of the GRC 360 Capability Model is nothing new, but simply the application of tried-and-true business performance enhancement techniques such as “lean” thinking, Six Sigma, and business process reengineering. However, what is totally revolutionary is that these techniques are being applied to a number of enterprise processes that, to date, have been considered completely separate and largely untouched by these powerful concepts.
When integration is realized, organizations see many benefits:
1. Improved Information Quality. Getting a single version of the truth is critical when certifying regulatory filings. You also need accurate information to understand whether the organization is operating within defined boundaries and on the path to achieving objectives. Integrated GRC systems allow governance, risk and compliance information to be shared and analyzed at varying levels of granularity.
2. Reduced Errors. As with any process, there are GRC “transactions” such as regulatory filings and internal certifications which, if botched, result in fines and penalties, up to and including jail time. Integrated GRC processes and systems help to reduce these errors through standardization, simplification and automation.
3. Reduced Costs. Leveraging common vocabulary, common process, common technology and, in some cases, common staff reduces overall costs to execute GRC processes. In addition, organizations using a common approach reduce the costs of external benchmarking as data gathering and normalizing (comparing apples-toapples) becomes less arduous.
Success Story - While integrating GRC is in its nascent stages, early adopters of the OCEG Framework are realizing value. For example, a leading chemical manufacturer improved workforce culture metrics by using an integrated approach. In the past, business unit executives and managers were annoyed with all the information requests for compliance-related activities. Between SOX 404, employment, security, privacy and other areas of compliance, they were completing up to seven surveys each year. When the organization took an integrated view, two surveys remained: one focusing on the culture and human capital issues and the other focusing on business risks and compliance risks of all types. The various GRC-related departments collaborated to develop these surveys using a common approach and a common tool for distribution and analysis.
The organization saved over 5,000 hours of labor (an estimated $500,000 of fully loaded costs) and approximately $50,000 of software and professional services. Most important were the culture metrics that dramatically improved in the business unit executive and management levels. Overwhelmingly, reporting went from, “compliance activities distract from our core business processes,” to, “compliance activities do not distract from our core business processes,” in only nine months.
Putting it All Together - Considering integrated GRC and Principled Performance can be daunting at first glance. The important thing to remember is that organizations going down this path have uniformly achieved success. OCEG’s GRC Strategy Study reports that 85 percent of those integrating GRC efforts met or exceeded their expectations for the outcome of that process. With the right commitment and approach, every organization, large or small, can drive Principled Performance and discover value in its GRC processes.
Enterprise Architecture Design and the Integrated Architecture Framework
http://msdn.microsoft.com/en-us/library/aa480017.aspx
ummary: Describes Cap Gemini Ernst & Young's Integrated Architecture Framework, and describes a model for enterprise architecture and its importance in helping software architects understand the business as a whole. (8 printed pages)
Contents
Enterprise Architecture in Context
Cap Gemini Ernst & Young's Integrated Architecture Framework
Communication and Architecture Governance
Linking Architecture and Design
Summary
Further Reading
Enterprise Architecture in Context
Over the past few years, and as software and systems engineering has matured, it has become accepted that there is a clear need for an 'architectural view' of systems. This need has grown as a result of the increasing complexity of systems and their interactions within and between businesses. Furthermore, continued pressure to reduce IT costs and deliver real, quantifiable business benefit from solutions necessitate a clear understanding of how systems support and enable the business.
The 'architectural view' of systems (both business and IT systems) is defined in the ANSI/IEEE Standard 1471-2000 as: 'the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution'. Further to this high-level definition, and in the same way as there are different levels of architecture within building (city plans, zoning plans and building plans), it is important to classify business and IT architecture into a number of different levels:
Enterprise Architecture. Defining the overall form and function of systems (business and IT) across an enterprise (including partners and organizations forming the extended enterprise), and providing a framework, standards and guidelines for project-level architectures. The vision provided by the Enterprise Architecture allows the development of consistent and appropriate systems across the enterprise with the ability to work together, collaborate, or integrate where and when required.
Project-Level Architecture. Defines the form and function of the systems (business and IT) in a project or programme, within the context of the enterprise as a whole and not just the individual systems in isolation. This project-level architecture will refine, conform to and work within the defined Enterprise Architecture.
Application Architecture. Defines the form and function of the applications that will be developed to deliver the required functionality of the system. Some of this architecture may be defined in the Enterprise and Project-level Architecture (as standards and guidelines) to ensure best-practice and conformance to the overall architecture.
When considering how organizations typically manage business change and IT enablement, traditional approaches to strategic business change use a top down view of the business in terms of its people and processes. However, the traditional software and systems engineering approaches tend to focus on identifying and delivering the specific functionality required to automate a task or activity. Less importance is attached to how the resulting system will interact with other systems and the rest the business in order to deliver wider business benefit. As a result, there is often a gap between the high level vision and structure of the business, and the systems implemented to support them (in other words the alignment between business and IT is poor).
To bridge this gap, many organizations are developing an enterprise architecture to provide a clear and holistic vision of how systems (both manual and automated) will support and enable their business. An effective enterprise architecture comprises a comprehensive view of the business, including its drivers, vision and strategy; the organization and services required to deliver this vision and strategy; and the information, systems and technology required for the effective delivery of these services (see Figure 1).
.gif "Click here for larger image.")
Figure 1. Business and Systems Alignment
Defining an enterprise architecture is complex, because it encompasses the systems within the context of the whole enterprise. To simplify this, an enterprise architecture is typically structured by considering a business or system as a series of components (or services) with inter-relationships, without having to consider the detailed design within the individual components.
Both the components and their inter-relationships must be viewed in terms of the services that they provide, and the characteristics, such as security, scalability, performance, integration, required of those services. These components can then be grouped by service characteristics, distribution and other business-driven aspects as well as functionality.
Although enterprise architecture should ideally be designed using a top down approach, many organizations have severe budget constraints for strategic IT initiatives which do not readily offer short-term return on investment or quantifiable business benefit. For this reason, many enterprise architectures are initially created as part of an approved large project or programme. Once in place there are opportunities to refine it further and to start demonstrating benefit and value by providing standards and guidelines for subsequent projects.
Cap Gemini Ernst & Young's Integrated Architecture Framework
Cap Gemini Ernst & Young has, over the past 10 years, developed an approach to the analysis and development of enterprise and project-level architectures know as the Integrated Architecture Framework (IAF). This approach, now its third major revision, has been developed at a global level-based on the experience of Cap Gemini Ernst & Young architects on real projects, together with a formal review process including academics. IAF has been successfully used on many hundreds of engagements, both large and small, across the globe.
IAF breaks down the overall problem into a number of the related aspect areas covering Business (people and process), Information (including knowledge), Information Systems, and Technology Infrastructure, with two specialist areas addressing the Governance and Security aspects across all of these. Analysis of each of these areas is structured into four levels of abstraction: Contextual, Conceptual, Logical and Physical, as shown in Figure 2.
.gif "Click here for larger image.")
Figure 2. Integrated Architecture Framework
This approach allows the pragmatic deployment of the framework in many different scenarios, both by using only the relevant parts of the framework and by supporting iterative working across the streams. This flexibility minimises the traditional effects of a waterfall approach and ensures coherency across the aspect areas. For example, a project architecture using IAF will, in many cases, only need to use sufficient of the Business and Information aspect areas to provide the overall context for the project. An enterprise architecture will concentrate mainly on the contextual, conceptual and logical levels.
The Contextual level brings together the business and other drivers, vision and strategy and their resulting priorities into a set of principles all of which are described with their implications and priorities. This comprehensive set of statements is then used in a consistent manner in the decision making process, providing traceability back to the original business drivers, strategy and vision, and demonstrating the required business-systems alignment.
Although much of the work done at this stage is concerned with data gathering, the importance of this stage cannot be overstressed. It will provide the basis for the entire architecture design by creating and documenting an understanding of the scope from an overall business perspective.
The Conceptual level details the services and the interactions between these services in support of the principles defined in the Contextual level. As the models defined in the Conceptual level are service-based (that is they do not detail specific products or standards), they remain stable unless the business itself fundamentally changes its vision and objectives; providing a solid foundation from which the logical architecture can be derived.
Key decisions taken at this level include:
- What areas of the business to use IT to support?
- Which overall business architecture (e.g. moving to a front-office, mid-office, back-office model) will be used?
- How systems will reflect the organization/business architecture, the level to which department systems are consolidated into a suite of core applications or are allowed departmental flexibility with a central integration service?
The Logical level describes the solution as product-independent services or components, includes a clear definition of the integration and collaboration contracts between these services or components. By remaining independent of products, this level of the architecture can remain relatively stable. It can change to reflect top-down changes, including new fundamental business models (for example a move towards a Customer-Centric model), as well as bottom-up changes, such as opportunities for technology enablement (such as CRM) or fundamental changes in technology paradigm (for example Services Architecture or Grid). Through this, the impact of change at the business or technology level can be assessed in a clear and consistent manner.
Key decisions taken at this level include:
- How should the logical components be grouped (for example, providing a multi-channel customer logon service with separate channel-specific/optimised authentication components alongside a common authentication support component using a central directory)?
- How will logical components be shared across systems (these components could be presented as Web services)?
- How a central integration hub supports the various business systems, or the way in which collaboration tools are used alongside databases applications and integration to support virtual team?
Typically, at the logical level, there might be more than one way to approach the solution (which reflects the various drivers, for example cost, flexibility, security, manageability). The key decision at this level is then to select (with the business) the solution alternative that delivers the services required, in a way that best addresses the guiding principles.
The Physical level details the design principles, standards and guidelines, including component grouping in critical areas as well as deployment models. This provides the framework within which the detailed design can be undertaken, as well as selection criteria (not functional specifications) for products to be either developed or purchased.
It is at this level that solution frameworks and architectures such as the Microsoft Systems Architecture (MSA) can be used at this level to accelerate development of the physical architecture, improve the quality of the architecture (by using proven solutions) and reduce project risks.
Examples of key decisions taken at this level are:
- Which physical components will be part of a package solution (e.g. using physical components from the ERP solution).
- What additional components will be required around this package, and the standards and guidelines for developing these components (e.g. language, tools, etc.)?
- What are the standards and detailed product selection criteria for the infrastructure products to be deployed?—leading onto a candidate list for selection. If there is a clear product or vendor strategy, this candidate list becomes the product standards to be taken forward.
Communication and Architecture Governance
Because of the large number of potential stakeholders, the enterprise architecture needs to be communicated at many different levels, using the appropriate visual representations and language: For senior management, the architecture must show how the business goals and drivers will be supported, and how benefit can be derived. The focus of business users is more on their own individual business areas and is more functionally biased. IT management and staff will want to focus on the technical components, including how they will be able to provide the required levels of support. Project-level architects will be concerned with the standards and guidelines, which will provide re-use opportunities or impose constraints on their individual designs.
Programs and projects must conform to the enterprise architecture to ensure that business benefits can be realized, and that the systems and software engineering activities can benefit from the analysis already done in defining the enterprise architecture. Furthermore, as with all architectures, the enterprise architecture requires ongoing maintenance, especially around the more physical areas such as technical standards. This ensures that the enterprise architecture remains valid and relevant to the business as it changes. The enterprise architecture should be under the control of an enterprise-wide governance function that ensures its maintenance and verifies the ongoing conformance of systems. Even where, for clear and justified business reasons, conformance is not possible, this function is then able to make sure that the business understands the real costs of implementing non-conformant systems, for example increased running costs or lack of future flexibility.
Linking Architecture and Design
As the use of the term 'architecture' has grown within business and IT, there have been many areas of confusion: for example, in many organizations, architecture and design are seen as being the same thing. It is Cap Gemini Ernst & Young's view that this is not the case because design and architecture offer different and complimentary perspectives on the solution—in fact, Cap Gemini Ernst & Young use IAF and the Rational Unified Process (RUP; a software development approach) on projects to deliver a complete design approach from architecture to code. Table 1 shows the comparison between architecture (IAF) and design (RUP, including application architecture):
Table 1. Comparing Architecture and Design
Delivers
Does Not Deliver
Architecture
- Non-functional requirements
- Functional scope and responsibilities (who does what)
- Key design and product choices
- High level design
- Design constraints
- Prototypes
- Comprehensive functional requirements
- Detailed data analysis
- Built and implemented systems
Design
- Functional requirements and how they will be met
- Detailed data analysis and data model as necessary
- System design documentation
- Built and implemented systems
- Solution Vision
- Comprehensive and traceable non-functional requirements
- Security and governance architectures
As with the architecture of buildings, software architecture and (detailed) design are, in fact, part of an overall 'design continuum' required to deliver a complete solution. Aligning IAF and RUP processes provides a comprehensive and consistent framework in support of this. Furthermore, the enterprise architecture will provide much of the context and other inputs required by the project architecture, whilst the project architecture will cater for the unique requirements of the solution.
In projects with significant potential risk, especially on complex or large projects, the use of the architectural approach at project-level will mitigate many of the risks by ensuring that there is a clear and holistic understanding of the overall context of the solution including external systems and drivers that may affect the solution.
With IAF, a project-level technical architecture uses the same basic approach as the enterprise architecture, albeit with different levels of detail, with more focus on the logical and physical level of information, information systems, technology infrastructure, governance and security aspects (using the context and business architecture defined in the enterprise architecture).
As a result, the output from the enterprise architecture can be used directly as the input into the project-level technical architecture. From the project-specific technical architecture, the detailed and specific design principles, guidelines, standards, and constraints, which then guide the detailed software and systems engineering design activities, can be derived. In the case of IAF, the output from the project-level technical architecture can be mapped onto RUP design artefacts such as business use cases, system use cases, and non-functional specification. These mappings typically are not one-to-one, but do provide traceability through from the architecture to the physical detailed design, as well as helping accelerate the overall design process from architecture through to delivered systems. This helps accelerate the design/development effort whilst continuing to mitigate project risks.
.gif "Click here for larger image.")
Figure 3. IAF and RUP
Summary
Enterprise architectures are becoming more important today as the level of complexity and inter-operation between systems and business increases, and as there is even more need for business-system alignment and cost-effective use of IT to deliver business benefit. Enterprise architecture (and project-level technical architecture) provides valuable input into application architecture and detailed design by helping architects understand the business as a whole and by placing the solution being designed into the overall business and technical context within which the project is being delivered.
The key objectives of an enterprise architecture are to understand ...
- The relevant parts of whole business, in context (incl. external partners)
- The end-to-end processes (including external processes/actors)
- Non-functional requirements (including security & governance)
which results in a solution that ...
- Supports the non-functional requirements. This may need specific component organization to support, for example, specific cross-domain security requirements, or a service-based approach to provide the required flexibility.
- Is seen in the context of the whole business and end-to-end processes. For example, service level objectives may exist for overall transaction times that span more than one business—understanding the limitations of this allow these measures to be refined.
- Links to, and is traceable to, the business principles so that the impact of changes, some of which may result from the design stage, can be evaluated in business terms.
- Drives, contextualises, and constrains the design. The design for the application or infrastructure will need to be governed by the architecture in order to fully deliver the complete solution including the non-functional requirements.
- Is clearly scoped, understood and clearly defines the responsibilities of each element.
and provides the rationale ...
- For decisions, standards and product selections that support the business goals and drivers.
Further Reading
Cap Gemini Ernst & Young Technology Services
About the author
Andrew Macaulay joined Cap Gemini Ernst & Young as a Technical Architect in 1993 following ten years as a Technical Consultant. He has been an Architect and Technical Consultant on many major engagements, both at an Enterprise and the Project level, and has been instrumental in developing, delivering and training Cap Gemini Ernst & Young's approach to architecture, Integrated Architecture Framework. Andrew can be reached at andrew.macaulay@cgey.com.
This article was published in the Architecture Journal, a print and online publication produced by Microsoft. For more articles from this publication, please visit theArchitecture Journal website.
This article was published in the Architecture Journal, a print and online publication produced by Microsoft. For more articles from this publication, please visit theArchitecture Journal website.
Business Architect Skills Assessment
Gabriel Morgan
Sharing experience as I help manage Microsoft Corp as an Enterprise Architect, Business Strategist, Business Performance Manager, Business Architect and Solution Architect. Twitter:@Gabriel_Morgan
http://blogs.msdn.com/b/gabriel_morgan/archive/2012/11/12/business-architect-skills-assessment.aspx
MEGA
hi
Business Architecture (BA)
http://www.mega.com/en/c/solution/p/ea/p2/business-architecture
Enterprise Architecture Management (EAM)
http://www.mega.com/en/c/solution/p/ea
Enterprise Architecture (EA)
lunes, 18 de febrero de 2013
ArchiMate, BPMN and UML together
http://www.strategicstructures.com/?p=124
The question about “the remaining role of UML now that ArchiMate has arrived” generated an interesting discussion on ArchiMate LinkedIn group. Adrian Champbell‘s first comment was:
Archimate was deliberately designed to be mappable to BPMN and UML, but not to replace them. Not parallel universes but complementary ones.
Archimate is for modelling at an Enterprise Architecture level of detail and not at the Solution Architecture and Software development level of detail. BPMN and UML have much more detail in them than ArchiMate.
Conversely neither BPMN or UML can replace ArchiMate either.
I agree with Adrian. Actually I find the idea of EA notation set comprising ArchiMate, BPMN and UML quite appealing. They are complimentary, although having some representation-types that could be redundant in a unified method. I use here ‘representation-type’ to avoid ‘model’ which means different things in UML and ArchiMate. There are other fundamental differences but we don’t have to deal with all of them. The three notations can co-exist quite well as they are. Especially when supported by a repository based tool with separated content and presentation space. It seems that what is needed in a big variety of use cases is already there or - if not – an extensions could take care of it. The rationale behind such a combination of ArchiMate, BPMN and UML is to have a relatively small number of notations that could satisfy most stakeholders and comply to some common modelling rules. Finding a good way to integrate these three languages could bring a lot of benefits. Coming to one universal notation turned out to be a difficult task, maintaining a dozen is neither efficient nor effective and then having several kept separated, used per project, could bring little benefit for the enterprise in the long run. Then how about these tree only, and well integrated?
There are two basic questions. How to make them play together? How to add what is missing?
Complexity is not a problem
hi
Complexity is not a problem
There is a common view in the enterprise architecture world that complexity is a big problem, perhaps the biggest problem, and that the primary task of enterprise architecture is to deal with this complexity.
- "The most pressing problem of the organization is complexity. Complexity is the primary responsibility of the enterprise architect." (Roger Sessions, Controlling Complexity in Enterprise Architecture pdf June 2007)
- "Enterprises are instances of complex adaptive systems having many interacting subcomponents whose interactions yield complex behaviors. Enterprise Architecture is a way of understanding and managing such complexity." (Beryl BellmanManaging Organizational Complexity pdf FEAC Oct 2009)
Indeed, I'm sure I've said things like this myself. But if complexity is a problem, whose problem is it? I am not seeing a huge rush of businessmen hiring enterprise architects just to deal with The Complexity Problem. Usually they have much more practical problems that they want addressing.
Complexity is a problem amplifier
So here's the thing. Apart from architects, people generally don't see complexity as their problem. What they do often acknowledge, however, is that complexity makes their problems worse. Furthermore, complexity may be one of the reasons they can't solve their problems for themselves. So complexity is a relevant factor, it's just not the problem itself.
Complexity as a lifestyle choice
And where does the complexity come from? Ironically, complexity is often created by failed attempts to reduce or eliminate complexity. In a post about the AntiFragile Enterprise (Jan 2013), Alan Hakami warns against "a tendency to build over-governed solutions that try to 'manage' complexity or uncertainty".
And where is the motivation to eliminate complexity? Suppose you go to the doctor with a headache, and the doctor says the reason you keep getting these headaches is you don't get enough fresh air and exercise. The pills just give you a temporary relief from the symptoms. You know she's right, but somehow you can't manage to get up early enough to go for a run before work. So you continue to get the headaches and you continue to need the pills. Indeed, if the pills work, you may start to exercise even less than you did before.
According to this analogy, an organization chooses the level of complexity it is comfortable with, and may well resist attempts to shift to a higher or lower level.
Complexity is an opportunity amplifier
If one organization is better at handling complexity than its competitors, as a consequence of superior agility and/or intelligence, then it can use complexity as a weapon. And many organizations use this weapon against customers or regulators. As @JackGavigan says, complexity is only a problem for those who lack the brain power to deal with and exploit it.
So that gives the enterprise architect a rather different perspective on complexity, doesn't it?
http://rvsoapbox.blogspot.com.es/2013/02/complexity-is-not-problem.html
Suscribirse a:
Entradas (Atom)