CMMI has been developed by the Carnegie Mellon University – Software Engineering Institute. It consists of best practices that address the development and maintenance of products and services covering the product life cycle from conception through delivery and maintenance.
CMMi provides a robust discipline to help developers achieve maturity in their software development processes. There are a number of factors that influence the maturity of the software development processes within an enterprise. These include the strategic plans of the enterprise, the enterprise’s own organization and culture, as well as the technologies that are adopted within the enterprise IT architecture.
A product can be an airplane, a digital camera, a drug or a software package available from a commercial retailer. It can also be a Service such as those defined into IT Service Management. CMMi integrates bodies of knowledge that are essential when developing products, but that have been addressed separately in the past, such as software engineering, systems engineering, and acquisition.
CMMi:
- Emphasizes the development of processes to improve product development and customer services in organizations.
- Provides a framework from which to organize and prioritize process improvement activities (product, business, people, technology)
- Supports the coordination of multi-disciplined activities that may be required to successfully build a product
- Emphasizes the alignment of process improvement efforts objectives with organizational business objectives
A CCMi model is not a process but describes the characteristics of effective processes. CCMI models could be used in conjunction with all IT processes found in Service Management (ITIL), COBIT, Project Management (SDLC/Prince 2), Enterprise Architecture (TOGAF), Quality (ISO 9000), Security Management (ISO 17799). CMMi allows companies to assess their practices and compare them to those of other companies. The CMMi measures process maturity, progresses through five levels: Level 1 (initial), 2 (managed), 3 (defined), 4 (predictable) and 5 (optimizing).
The CMM has been applied to several disciplines within different industries. It is not surprising that maturity models have also been applied to IT Service Management (ITSM).
Recently, the Vrije Universiteit Amsterdam and CIBIT, published a very interesting document “The IT Service CMM” which is free to download and use. This should help companies to evaluate their level of maturity for their ITIL processes, using the CMMi framework.
25 October, 2006
24 October, 2006
Is IT Service Management an emerging component of Enterprise Architecture?
There is a high level of correlation between success at Enterprise Architecture and commitment to ITIL. ITIL is a standardized approach and series of documents that are used to aid the implementation of a framework for IT Service Management. This customizable framework defines how ITSM is applied within an organization, covering processes such as service desk management, incident management, problem management, configuration management, change management, and release management among others.
Enterprise architecture consists of the vision, principles, standards and processes that guide the purchase, design and deployment of technology within an enterprise. It describes the interrelationships between business processes, information, applications and underlying infrastructure for that enterprise. Processes such as availability management, change management or release management are just business processes that are particular to IT. So we can think of IT service management as another use case or usage scenario for Enterprise Architecture.
Many frameworks such as FEAF, DODAF, Zachman and TOGAF among others do not yet consider the relationship to Service Management. Any component of architecture has to change, solves a problem, or relates to a set of software and infrastructure. Business Architecture is all about documenting, changing, viewing specific business processe and makes them more efficient. Business Architecture also allows to understand the business impacts of new products introductions or modifications. Products should be delivered as services and be manages by Service Level agreements.
New products also have to consider its availability and its capacity to perform, based on user requirements.
This demonstrates that running an Enterprise Architecture program, has a lot to do with Service Management! Service Management also has a lot to learm from Enterprise Architecture… As an example, the definition of EA Technical Services can help to build departmental IT Service Catalogues related to Customers Service Catalogues.
Enterprise architecture consists of the vision, principles, standards and processes that guide the purchase, design and deployment of technology within an enterprise. It describes the interrelationships between business processes, information, applications and underlying infrastructure for that enterprise. Processes such as availability management, change management or release management are just business processes that are particular to IT. So we can think of IT service management as another use case or usage scenario for Enterprise Architecture.
Many frameworks such as FEAF, DODAF, Zachman and TOGAF among others do not yet consider the relationship to Service Management. Any component of architecture has to change, solves a problem, or relates to a set of software and infrastructure. Business Architecture is all about documenting, changing, viewing specific business processe and makes them more efficient. Business Architecture also allows to understand the business impacts of new products introductions or modifications. Products should be delivered as services and be manages by Service Level agreements.
New products also have to consider its availability and its capacity to perform, based on user requirements.
This demonstrates that running an Enterprise Architecture program, has a lot to do with Service Management! Service Management also has a lot to learm from Enterprise Architecture… As an example, the definition of EA Technical Services can help to build departmental IT Service Catalogues related to Customers Service Catalogues.
17 October, 2006
Training-evening SMP (Société Suisse de Management de Projet)
1st nov. Lausanne : Training-evening SMP:
ITIL : A Service Management implementation and the evolution to an Operational Excellence
by Serge Thorn (XXXXXX and itSMF Chairman)
Details and registration
ITIL : A Service Management implementation and the evolution to an Operational Excellence
by Serge Thorn (XXXXXX and itSMF Chairman)
Details and registration
16 October, 2006
Enterprise Architecture and Service Management
Enterprise Architecture Practitioners Conference Lisbon
Lisbon, Portugal October 23-25 , 2006
STREAM #2:Enterprise Architecture Development Tuesday October 24
16:00 – 16:45 Enterprise Architecture and Service Management Serge Thorn, Director IT Research & Innovation (Switzerland)
Synopsis:
Is IT Service Management an emerging component of Enterprise Architecture? There is a high level of correlation between success at Enterprise Architecture and commitment to ITIL. ITIL is a standardized approach and series of documents that are used to aid the implementation of a framework for IT Service Management. This customizable framework defines how ITSM is applied within an organization, covering processes such as service desk management, incident management, problem management, configuration management, change management, and release management among others. Enterprise architecture consists of the vision, principles, standards and processes that guide the purchase, design and deployment of technology within an enterprise. It describes the interrelationships between business processes, information, applications and underlying infrastructure for that enterprise. Processes such as availability management, change management or release management are just business processes that are particular to IT. So we can think of IT service management as another use case or usage scenario for Enterprise Architecture. This session will cover (xxx) roadmap and reflections in these two domains.
Lisbon, Portugal October 23-25 , 2006
STREAM #2:Enterprise Architecture Development Tuesday October 24
16:00 – 16:45 Enterprise Architecture and Service Management Serge Thorn, Director IT Research & Innovation (Switzerland)
Synopsis:
Is IT Service Management an emerging component of Enterprise Architecture? There is a high level of correlation between success at Enterprise Architecture and commitment to ITIL. ITIL is a standardized approach and series of documents that are used to aid the implementation of a framework for IT Service Management. This customizable framework defines how ITSM is applied within an organization, covering processes such as service desk management, incident management, problem management, configuration management, change management, and release management among others. Enterprise architecture consists of the vision, principles, standards and processes that guide the purchase, design and deployment of technology within an enterprise. It describes the interrelationships between business processes, information, applications and underlying infrastructure for that enterprise. Processes such as availability management, change management or release management are just business processes that are particular to IT. So we can think of IT service management as another use case or usage scenario for Enterprise Architecture. This session will cover (xxx) roadmap and reflections in these two domains.
12 October, 2006
Business Continuity and Business Architecture
Are there any potential relationships between these two domains? Maybe yes…
Very often Enterprise Architecture programs start with a bottom up approach as this is easier to justify. A bottom-up approach involves setting infrastructure standards and introducing governance processes to ensure adherence to those standards, while a top-down approach dictates a formal analysis of the current state with respect to business process, application programs, data, and technology components.
Top-down start with Business Architecture once the Business strategy and organization is well known, but how to be able to quickly justify some sort of return on investment when no real Business Process Management initiative is associated?
Disaster recovery efforts can be extremely costly, both in terms of technology replacement and business interruption. But giving users access to the exact same work information through another connectivity path is a big step toward business continuity.
Often a major factor in the decision to provide only limited recovery facilities is the cost of having “redundant” office space ready to use just in case of an incident. These limited recovery facillities are associated to limited IT Services because rarely all applications and systems have redundancy. Choices have to be made… but on what criterias? How do we manage existing Business Processes if these are no more automated?
Business Architecture can be an answer!
Business Architecture programs limit the depth of the program to business architecture, and are typically driven from the top-down, with corporate planning and strategy, or change management as the sponsor of the program. The architecture team is typically comprised of business process experts, and has a close relationship to their specific Lines of Business. Business Architecture teams in companies that are “process organizations” typically have the mandate to define business processes that span the company.
Associating Business Architecture to Business Continuity can therefore help to quickly justify a top-down approach as key processes needs to be documented for a disaster recovery effort.
Very often Enterprise Architecture programs start with a bottom up approach as this is easier to justify. A bottom-up approach involves setting infrastructure standards and introducing governance processes to ensure adherence to those standards, while a top-down approach dictates a formal analysis of the current state with respect to business process, application programs, data, and technology components.
Top-down start with Business Architecture once the Business strategy and organization is well known, but how to be able to quickly justify some sort of return on investment when no real Business Process Management initiative is associated?
Disaster recovery efforts can be extremely costly, both in terms of technology replacement and business interruption. But giving users access to the exact same work information through another connectivity path is a big step toward business continuity.
Often a major factor in the decision to provide only limited recovery facilities is the cost of having “redundant” office space ready to use just in case of an incident. These limited recovery facillities are associated to limited IT Services because rarely all applications and systems have redundancy. Choices have to be made… but on what criterias? How do we manage existing Business Processes if these are no more automated?
Business Architecture can be an answer!
Business Architecture programs limit the depth of the program to business architecture, and are typically driven from the top-down, with corporate planning and strategy, or change management as the sponsor of the program. The architecture team is typically comprised of business process experts, and has a close relationship to their specific Lines of Business. Business Architecture teams in companies that are “process organizations” typically have the mandate to define business processes that span the company.
Associating Business Architecture to Business Continuity can therefore help to quickly justify a top-down approach as key processes needs to be documented for a disaster recovery effort.
05 October, 2006
CMDB and SOA registries convergence
Without doubt we will see a convergence between Service Desk CMDB’s and SOA Registries and repositories. SOA Governance solutions should cover several features such as (this is not exhaustive) :
- The governance itself (design, deployment, amd the run-time)
- Policies management
- The Service Life cycle Management
o Service Deployment
o Service management and monitoring
o Service publishing
o Service specification
o Service acquisition
o Service assembly
o Service testing
o Service design
o Service integration
o Service build and test
o Service asset management and publishing
- Contract Management
- Impact Management
- The Service Discovery and mediation
- Etc.
But we can foresee more an integration in terms of relationship that a full integrated solutions. In others terms the Service Life Cyle will require a Service to be managed in Service Management terms. A Web service will have incidents, be changed be released etc…
As en example, IBM just announced Websphere Service Registry and Repository. This solution will communicate with Tivoli CCMDB which will manage Changes and Configuration.
HP which acquired Mercury and Peregrine….also acquired Systinet, another SOA Governance solution. All the first 3 vendors have their CMDB, and once eventually integrated, wouldn’t this make sense to have connections between the Systinet Repository and “one of the HP CMDB”?
- The governance itself (design, deployment, amd the run-time)
- Policies management
- The Service Life cycle Management
o Service Deployment
o Service management and monitoring
o Service publishing
o Service specification
o Service acquisition
o Service assembly
o Service testing
o Service design
o Service integration
o Service build and test
o Service asset management and publishing
- Contract Management
- Impact Management
- The Service Discovery and mediation
- Etc.
But we can foresee more an integration in terms of relationship that a full integrated solutions. In others terms the Service Life Cyle will require a Service to be managed in Service Management terms. A Web service will have incidents, be changed be released etc…
As en example, IBM just announced Websphere Service Registry and Repository. This solution will communicate with Tivoli CCMDB which will manage Changes and Configuration.
HP which acquired Mercury and Peregrine….also acquired Systinet, another SOA Governance solution. All the first 3 vendors have their CMDB, and once eventually integrated, wouldn’t this make sense to have connections between the Systinet Repository and “one of the HP CMDB”?
02 October, 2006
Configuration Management: Are there any Auto discovery tool companies left?
Eighteen months ago, the market counted something like a dozen of companies which were selling interesting products named “Auto discovery or mapping tools” (refer to my other post: Configuration Management: How to really build a CMDB with an auto discovery tool). Among them, there were, Appilog, Collation, Relicore, n-layers, Tideway Systems, Cendura.
Since that time, important software companies have considered these tools as probably being highly strategic because they would help to materialize Configuration Management , one of the most complex ITIL process.
IBM, Symantec, Mercury among others have acquired some of these companies, and the remaining ones would soon be considered for acquisition. That was my impression… end of last year.
Today Computer Associates has acquired Cendura, a small company (50 people) located in the Silicon Valley which also provide a nice Auto Discovery funtion with lots of granularity (the level of drilldown is quite impressive). This demonstrates clearly that without such functionality, Configuration Management was an unreachable ITIL process and irrealistic to be correctly implemented.
Since that time, important software companies have considered these tools as probably being highly strategic because they would help to materialize Configuration Management , one of the most complex ITIL process.
IBM, Symantec, Mercury among others have acquired some of these companies, and the remaining ones would soon be considered for acquisition. That was my impression… end of last year.
Today Computer Associates has acquired Cendura, a small company (50 people) located in the Silicon Valley which also provide a nice Auto Discovery funtion with lots of granularity (the level of drilldown is quite impressive). This demonstrates clearly that without such functionality, Configuration Management was an unreachable ITIL process and irrealistic to be correctly implemented.
Subscribe to:
Posts (Atom)
