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!
29 April, 2008
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.
Subscribe to:
Posts (Atom)