There are plenty of comparisons between architecture frameworks and the one I like is written by Roger Sessions from Objectwatch, Inc.
http://msdn.microsoft.com/en-us/library/bb466232.aspx
However when you need to explain this to your IT Management or to any decision maker, it becomes a real challenge.
Below is a section of an internal employer email recently sent to explain the role of Enterprise Architecture and how it helps to develop business solutions for people using technology. It uses the analogy of undertaking a trip to explain how the architecture can help on that journey.
...It takes quite some time in convincing people that the decision is not TOGAF or DODAF or FEAF etc. but using just enough of each architecture framework to produce a functionally elegant, minimally complex and maximized compliant solution.
It describes the differences between the frameworks somewhat more simplistically: Zachman is like the map at a low resolution.
TOGAF is like the directions on the map that will lead us to some destination (it may be a good or bad destination).
FEAF contains specific information such as the reference models which act like the road rules and speed limits and communication protocols of our mobile phones, etc. (these are the sensible and logical constraints).
MODAF / DODAF and other defense architecture frameworks describe how our vehicle, which we are using to undertake our journey, is constructed, supported, used, etc (say a bike or a car).
Always refer back to Zachman when you are lost. (Overcome with complexity).
Refer to TOGAF at specific milestones in the journey. (Preparing for reviews, checking completeness of the architecture, etc.).
FEAF reference models for what technologies, constraints, resources, etc that can be used in the architecture.
DODAF when redesigning or designing or specifying explicitly a ‘widget’ in the architecture. (Widget may be a solution agnostic architectural building block or a solution dependent solution building block)...
19 December, 2008
Which Enterprise Architecture Framework are you using?
Linkedin introduced recently a new feature: Polls.
I wanted to test that feature and created a poll with the main EA frameworks. Unfortunately, this is limited to 5 and I have not been able to include something like "others" or "proprietary".
Furthermore it is not possible to select several.
If interested, you can access this with
http://polls.linkedin.com/p/13540/ikhnz
Interesting results!
I wanted to test that feature and created a poll with the main EA frameworks. Unfortunately, this is limited to 5 and I have not been able to include something like "others" or "proprietary".
Furthermore it is not possible to select several.
If interested, you can access this with
http://polls.linkedin.com/p/13540/ikhnz
Interesting results!
29 April, 2008
IT Governance, finally a worldwide recognition: ISO 38500
Finally IT Governance will be recognised as a standard. We already had a series of ISO standards for various IT Governance domains such as IT Service Management ISO 20000, Security Management ISO 27001, and Quality ISO 9000, but recently the international organization recognized that a new standard would be well accepted. It will be named ISO 38500 which will cover Corporate Governance of information technology. This standard was originally defined as an Australian standard AS8015, which by the way was the only alternative available.
AS8015 is (was?) intended to provide guiding principles to any organisation, from the smallest to the largest, including private and public (listed and unlisted) companies, not-for-profit organisations, associations, clubs and government agencies. This standard has an application to just about any organisation, either because you are a supplier of ICT related goods and services or more simply because you implement and use ICT in your business.
AS8015 provides six guiding principles for good corporate governance and the effective, efficient and acceptable use of ICT. The six principles (and examples of each) are:
1 Establish clearly understood responsibilities for ICT (eg, ensure individuals understand and accept their responsibilities)
2 Plan ICT to best support the organisation (eg, ensure ICT plans fit current and future needs and the organisation’s corporate plans)
3 Acquire ICT validly (eg, ICT acquisitions should be made for approved reasons and in the approved way; on the basis of ongoing analysis)
4 Ensure ICT performs well, whenever required (eg, ensure ICT is fit for its purpose and is responsive to changing requirements)
5 Ensure ICT conforms with formal rules (eg, ensure compliance with external regulations and internal policies and practices)
6 Ensure ICT use respects human factors (eg, ensure ICT meets the evolving needs of the ‘people in the process’)
The following ISO website used to be where the draft was located (different number) but if you want more information you may refer to
http://www.ramin.com.au/itgovernance/as8015.html
The 26th of May, the standard will be launched in the Netherlands. As any ISO standards, this will impact how IT Departments are organized!
AS8015 is (was?) intended to provide guiding principles to any organisation, from the smallest to the largest, including private and public (listed and unlisted) companies, not-for-profit organisations, associations, clubs and government agencies. This standard has an application to just about any organisation, either because you are a supplier of ICT related goods and services or more simply because you implement and use ICT in your business.
AS8015 provides six guiding principles for good corporate governance and the effective, efficient and acceptable use of ICT. The six principles (and examples of each) are:
1 Establish clearly understood responsibilities for ICT (eg, ensure individuals understand and accept their responsibilities)
2 Plan ICT to best support the organisation (eg, ensure ICT plans fit current and future needs and the organisation’s corporate plans)
3 Acquire ICT validly (eg, ICT acquisitions should be made for approved reasons and in the approved way; on the basis of ongoing analysis)
4 Ensure ICT performs well, whenever required (eg, ensure ICT is fit for its purpose and is responsive to changing requirements)
5 Ensure ICT conforms with formal rules (eg, ensure compliance with external regulations and internal policies and practices)
6 Ensure ICT use respects human factors (eg, ensure ICT meets the evolving needs of the ‘people in the process’)
The following ISO website used to be where the draft was located (different number) but if you want more information you may refer to
http://www.ramin.com.au/itgovernance/as8015.html
The 26th of May, the standard will be launched in the Netherlands. As any ISO standards, this will impact how IT Departments are organized!
21 April, 2008
IT Architecture is not Enterprise Architecture
For many years I have observed lots of confusion with some basic definitions such as IT and Enterprise Architecture among other terms. I will not try to define the meaning of Enterprise Architecture by myself (despite I have my own view on this) as this is something being right now redefined by the Open Group (which by the way used to call their events “IT Architecture Practitioner Conference” and changed only recently to “Enterprise Architecture Practitioner Conference”).
Looking at job definitions related to Architecture positions, I have also identified a clear misunderstanding of “who is supposed to be doing what…”. In addition to that, I’m frequently asked “what’s the difference between an Enterprise Architect and an IT Architect”.
First, let’s assume that everyone agrees on the fact that Enterprise Architecture includes
-Business Architecture
-Information Architecture
-Application Architecture
-Technology Architecture
Whatever the framework is.
One of the main differences between Enterprise Architecture and IT Architecture is the Business Architecture. The diagram below explains at a high level the purpose of each layer.
Among other activities, an Enterprise Architect will drive, supervise and review technology diagnosis and assessment activities. He will be an active member for the IT Strategy development, identify opportunities for technology-related improvement based on benchmark data and doing high-level cost benefit analysis-(Contribution to the overall alignment of IT delivery to the needs of the business). He will develop the enterprise architecture artifacts including current state architecture, target state architecture, architectural roadmaps, referential architecture patterns and technology standard. Also I recommend he acts as a solution architect during the pre-project and development phases of an IT program or oversight of future state designs including technology, solution, information and business architecture. Other activities are related to the access to the future state architecture for adherence to target state direction, or validate deviation justification and recovery plans.He may develop and implement training and documentation for enterprise architecture processes, procedures and framework, work with a team, coordinate, review and integrate the deliverables of information and technology architects into cohesive solutions architecture, taking into account the user requirements, technical requirements, etc.
An IT Architect could be an experienced software engineer with experience in cross-platform, cross-regional application architectures. He would be exposed to modern software engineering methodologies, such as object oriented analysis and design, web architectures, design patterns, iterative-incremental software development, test-first. He should also be familiar with the following methods and platforms: UML, J2EE, .NET, relational databases. And finally experienced in documenting and communicating software architecture, including communication to key senior stakeholders in business
There are various definitions of these roles. Most of them are clearly defined in some frameworks, but there are still lots of confusion in the market and among recruiters.
Looking at job definitions related to Architecture positions, I have also identified a clear misunderstanding of “who is supposed to be doing what…”. In addition to that, I’m frequently asked “what’s the difference between an Enterprise Architect and an IT Architect”.
First, let’s assume that everyone agrees on the fact that Enterprise Architecture includes
-Business Architecture
-Information Architecture
-Application Architecture
-Technology Architecture
Whatever the framework is.
One of the main differences between Enterprise Architecture and IT Architecture is the Business Architecture. The diagram below explains at a high level the purpose of each layer.
Among other activities, an Enterprise Architect will drive, supervise and review technology diagnosis and assessment activities. He will be an active member for the IT Strategy development, identify opportunities for technology-related improvement based on benchmark data and doing high-level cost benefit analysis-(Contribution to the overall alignment of IT delivery to the needs of the business). He will develop the enterprise architecture artifacts including current state architecture, target state architecture, architectural roadmaps, referential architecture patterns and technology standard. Also I recommend he acts as a solution architect during the pre-project and development phases of an IT program or oversight of future state designs including technology, solution, information and business architecture. Other activities are related to the access to the future state architecture for adherence to target state direction, or validate deviation justification and recovery plans.He may develop and implement training and documentation for enterprise architecture processes, procedures and framework, work with a team, coordinate, review and integrate the deliverables of information and technology architects into cohesive solutions architecture, taking into account the user requirements, technical requirements, etc.
An IT Architect could be an experienced software engineer with experience in cross-platform, cross-regional application architectures. He would be exposed to modern software engineering methodologies, such as object oriented analysis and design, web architectures, design patterns, iterative-incremental software development, test-first. He should also be familiar with the following methods and platforms: UML, J2EE, .NET, relational databases. And finally experienced in documenting and communicating software architecture, including communication to key senior stakeholders in business
There are various definitions of these roles. Most of them are clearly defined in some frameworks, but there are still lots of confusion in the market and among recruiters.
28 March, 2008
Business Architecture may help to get ISO 9001:2000 certification
The ISO standard is related to the definition and requirements of a quality management system. It helps an organization to operate with increased effectiveness, consistency and customer satisfaction and have the capability to continually improve the management system.
ISO 9001:2000 is based on eight Quality Management Principles which are comprehensive and fundamental rules of belief, for leading and operating an organization, aimed at continually improving performance over the long term, by focusing on customers, while addressing the needs of all stakeholders.
Principle 4 is referring to a “Process Approach”. The standard promotes the adoption of a process approach when developing, implementing and improving the effectiveness of the quality management system. A desired result is achieved more efficiently when activities and related resources are managed as a process.
Product realization is a system of processes by which inputs, such as raw materials or components from suppliers, are transformed through the activities of the organization, such as value added production or assembly operations, into outputs, such as products or components, which meet the needs and requirements of a customer.
Any activity or operation that receives inputs and converts them into outputs can be considered as a process. Almost all activities and operations involved in making a product or providing a service are processes.
When an Enterprise Architecture Committee receives suggestions for strategic changes, they should immediately translate those changes into changes in specific business processes. If the architecture is well-defined, changes in processes will immediately suggest changes in specific applications and databases. There are many definitions of a Business Architecture but they all refer to the definition of processes.
The business architecture is a formal documentation of the lines of business, their support functions and their relationship to each other. After the architecture has been documented, it is systematically analyzed to examine the functions (services) required by business and to align the enterprise technology with those functions.
Companies which have already documented their business architecture (baseline/as-is) may consider to have achieved a great step getting the ISO 9001:2000 certification.
ISO 9001:2000 is based on eight Quality Management Principles which are comprehensive and fundamental rules of belief, for leading and operating an organization, aimed at continually improving performance over the long term, by focusing on customers, while addressing the needs of all stakeholders.
Principle 4 is referring to a “Process Approach”. The standard promotes the adoption of a process approach when developing, implementing and improving the effectiveness of the quality management system. A desired result is achieved more efficiently when activities and related resources are managed as a process.
Product realization is a system of processes by which inputs, such as raw materials or components from suppliers, are transformed through the activities of the organization, such as value added production or assembly operations, into outputs, such as products or components, which meet the needs and requirements of a customer.
Any activity or operation that receives inputs and converts them into outputs can be considered as a process. Almost all activities and operations involved in making a product or providing a service are processes.
When an Enterprise Architecture Committee receives suggestions for strategic changes, they should immediately translate those changes into changes in specific business processes. If the architecture is well-defined, changes in processes will immediately suggest changes in specific applications and databases. There are many definitions of a Business Architecture but they all refer to the definition of processes.
The business architecture is a formal documentation of the lines of business, their support functions and their relationship to each other. After the architecture has been documented, it is systematically analyzed to examine the functions (services) required by business and to align the enterprise technology with those functions.
Companies which have already documented their business architecture (baseline/as-is) may consider to have achieved a great step getting the ISO 9001:2000 certification.
13 March, 2008
Business Architecture and Capability Modeling
Capability modeling is an emerging technique for analyzing a business and modeling it in terms of its competencies. Capabilities are the building blocks of business. A business capability tipically defines what a business unit‘s purpose is, its core competencies, and is therefore directly bound to business objectives and strategy.
Capabilities provide a black-box view of those things the business can do, i.e. working on business artifacts. The business processes and resources involved in providing the capability are not exposed (business service orientation). Capabilities aren‘t isolated but form hierarchical value-networks with relationships that materialize the business processes. At a lower level, capabilities are modeled using traditional activities diagrams used for the implementation of IT solutions.
The key benefit that capability modeling provides over business process modeling is that it focuses on those elements of the business that are the most stable, and therefore facilitates the alignment with key IT initiatives, especially SOA adoption programs, which can leverage stable business concepts rather than process activities that are continuously evolving.
Outputs of capability modeling activities are direct inputs into the activities of service identification, definition and interface design (SOA).
Modeling effort should be done incrementally, with focus on key business initiatives first.
Capabilities modeling has proven to be particularly efficient in allowing to solve business issues not addressable in other ways. It also eases the deployment of business activity monitoring, providing the insight the business needs to adapt to environmental changes or identify new opportunities.
Capabilities provide a black-box view of those things the business can do, i.e. working on business artifacts. The business processes and resources involved in providing the capability are not exposed (business service orientation). Capabilities aren‘t isolated but form hierarchical value-networks with relationships that materialize the business processes. At a lower level, capabilities are modeled using traditional activities diagrams used for the implementation of IT solutions.
The key benefit that capability modeling provides over business process modeling is that it focuses on those elements of the business that are the most stable, and therefore facilitates the alignment with key IT initiatives, especially SOA adoption programs, which can leverage stable business concepts rather than process activities that are continuously evolving.
Outputs of capability modeling activities are direct inputs into the activities of service identification, definition and interface design (SOA).
Modeling effort should be done incrementally, with focus on key business initiatives first.
Capabilities modeling has proven to be particularly efficient in allowing to solve business issues not addressable in other ways. It also eases the deployment of business activity monitoring, providing the insight the business needs to adapt to environmental changes or identify new opportunities.
Modeling of Business Operations (Operational modeling), using UML diagrams:
Based on Business Artifacts (artifact-centered operational modeling), which requires:
- Key Business Artifacts identification
- Artifacts life-cycle definitions
- Business tasks identification (BPMN modeling)
- Repository building for artifacts
- Flow components
05 March, 2008
Differences between IT Governance and Enterprise Architecture Governance
IT Governance is the responsibility of the board of directors and executive management of an IT department. It is an integral part of the enterprise governance and consists of the leadership and organizational structures and processes that ensure that the organization's IT sustains and extends the organization's strategies and objectives.
IT Governance ensures that
We may consider defining an IT Governance team which would care of various domains such as Project Portfolio Management, Security Management, Project Management, COBIT, SOX, Risk Management ,Service Management, ISO 9000, etc..
Enterprise Architecture Governance encompasses leadership, implementation and controlling of Business Architectures, IT Architectures (Information, Application, Technology architectures) and Solution Architectures including organizational structures (organizational units as well as processes and roles) to ensure that architecture sustains and extends the business strategy and objectives. When we implement an EA Governance, we may consider defining an Architecture Review Board which decides which IS is best suited for the needs of the enterprise, it decides when a change in the architecture is needed, and prioritizes initiatives. More detailed explanation on this other post.
To summarize Enterprise Architecture is one of the IT Governance pillars and Enterprise Architecture with its associated Governance is s subdomain.
IT Governance ensures that
- IT delivery expectations are fulfilled
- IT resources deployment is continuously planned, targeted and optimized
- IT performance is measurable
- and that the risks are minimized
We may consider defining an IT Governance team which would care of various domains such as Project Portfolio Management, Security Management, Project Management, COBIT, SOX, Risk Management ,Service Management, ISO 9000, etc..
Enterprise Architecture Governance encompasses leadership, implementation and controlling of Business Architectures, IT Architectures (Information, Application, Technology architectures) and Solution Architectures including organizational structures (organizational units as well as processes and roles) to ensure that architecture sustains and extends the business strategy and objectives. When we implement an EA Governance, we may consider defining an Architecture Review Board which decides which IS is best suited for the needs of the enterprise, it decides when a change in the architecture is needed, and prioritizes initiatives. More detailed explanation on this other post.
To summarize Enterprise Architecture is one of the IT Governance pillars and Enterprise Architecture with its associated Governance is s subdomain.
26 February, 2008
ITIL V3 Demand Management and...Demand Management
In one of my previous post I was referring to the definition of Demand Management and how this related to Requirements management and Project Portfolio Management.
With ITIL V3, Demand Management is part of Service Strategy and does not mean the same!!! This will for sure create some confusion for some people.
ITIL Demand Management’s objectives are to optimize the use of capacity by moving workload to less utilized times, servers, or places…. (Nothing to do with users having business requirements!).
This new process refers to:
- Activity-based Demand Management. Analyzing and tracking the activity patterns of the business process makes it possible to predict demand for service assets that support those services.
- At a strategic level, Demand Management can involve analysis of Pattern of Business Activity (PBA) and user profiles. Each profile can be associated to one or more PBA.
- At a tactical level it can involve use of differential charging to encourage Customers to use IT Services at less busy times.
- Service packages. They represent the value that the customer wants and for which they are willing to pay.
The key elements of the ITIL V3 Demand Management refers to:
o Core/supporting services
o Developing differentiated offerings
o Service Level Packages
o Advantage of core service packages
o Segmentation
Even these concepts may appear no to be crystal clear…
01 February, 2008
Service Management and Enterprise Architecture
An article I wrote for OpenSource magazine published yesterday, you may comment here!
http://opensource.sys-con.com/read/493465.htm
http://opensource.sys-con.com/read/493465.htm
Subscribe to:
Posts (Atom)
