20 December, 2006
This post is the follow up to a previous article I wrote a while ago:
What is a Service?
It is important to specify that sometimes when people talk, the term Service has to be considered either as an ITSM Service or an SOA Service-web service. This is clear to me that BPM and SOA should be tightly integrated, but let’s look at this slightly differently…
A Business Process has activities. An activity could be one to many Services.
But you can also look at this in another way...
A Service is one to many Business Processes. A Business Process has activities, and as already said, an activity is one to many Services. Isn’t this confusing?
What I try to say is that we need to be clear (at least for me...) when we talk of a Service. Are we talking of Service in Service Management terms, or in SOA Terms?
As an example:
The Service "e-mail" has several Business Processes such has:
Creation of email, classification, forwarding, etc...
Calendar Management, invitation for meetings, reminders, etc..
If for example we define the Calandar Management process and look at activities, maybe at some stage we would define a Service which lookup for availability of people in a meeting. This would be an SOA Service "Availability of people"...
To summarize and be clear, I would claim that ITSM Services could count one to many Business Processes, and Business Processes could one to many SOA Services. “E-mail” is an ITSM Service and “creation of an email” being a transaction is an SOA Service.
Does this make sense?
11 December, 2006
Then that team starts to develop a target Business Architecture describing the product and/or service strategy, and the organizational, functional, process, event, information, and geographic aspects of the business environment.
There must be then an analysis related to the gaps between the Baseline and the Target Business Architecture. As with the Baseline artifacts, the Target architecture information should be captured in with a phased approach with the organization Enterprise Architecture stakeholders and senior management. Once populated, the variance between the existing baseline, view and the transitional and future, target, views is used to identify the performance gaps in the Enterprise Architecture. The Performance Gap (also know as the transition strategy information to migrate the organization from its “As-Is” architecture to the organization “To-Be” architecture) information is then used to help identify what investments need to be supported for funding and implementation.
But during this Gap analysis phase, the Enterprise Architect plays a fundamental role in enabling business innovation, and facilitating the provision of a flexible and resilient infrastructure. His role will be to manage and incubate successful ideas through to implementation, as the Business is always looking at innovations in products, services, and business models to drive growth and profits.
A good Enterprise Architect also needs to be an innovator.
Innovation is critical, especially in today’s rapidly changing technology and business landscape. Having a n Enterprise Architecture that supports an IT Strategy and provides the flexibility to achieve the right balance between IT efficiency and business innovation is a keystone to business adaptability and growth.
08 December, 2006
In other words, BMC, Fujitsu, IBM and HP decided to create a model for a CMDB which would allow storing information such as desktop and laptop client images or configurations, servers, storage pools or networks and so on.
Very often information is spread among various sources and no standards exist on how to exchange meta data from all these potential sources of CMDB information. Today, the CMDB interfaces that exist are all proprietary, which is the problem that this group wants to tackle.
This working group will issue a white paper within the next month that will spell out their initial goals in more detail. And by the end of the year, they hope to have a draft specification proposal, at which point they hope to formalize the process by choosing a standards body.
But is that enough?
Focusing on data exchange is fine but shouldn’t they also consider the CMDB Meta data and propose a common model eventually re-usable by third parties?
All vendors’ CMDB have their own Meta model and as from now I have never seen from any vendor a roadmap related to the repository. As an example, with the acquisition of both Mercury and Peregrine, HP initially announced the migration from the HP Openview Service Desk, to Service Center, and now has announced that next CMDB would be the one from Mercury, which is in fact…Appilog… (An acquisition from Mercury). So what!
There is a need for a “next generation CMDB” for the following reasons:
- BPM based on a SOA architecture invoque IT components (software on hardware…) and we should have a link between a Business Process and the underlying Cis. A CMDB should also be process based.
- Relation is important that’s for sure but dependencies is another key topic. How does infratructure relates one to the other, how information relates one to the other, how physically components relates one to the other, how does application code relates (Cendura acquired by CA is maybe one of the only company which deleivred that capability) etc… A CMDB should be also able to add dependencies on the top of relationships.
This initiative will help the concept of federated CMDB and information exchange but will not really look at today’s requirements… A unified Meta model could be an interesting initiative for these vendors as this would create a new generation of unified Service management/Business Process management solutions.
05 December, 2006
An IT Process is also a Business Process. It has only an “IT Flavour”.
Looking at the Business side, Business Process Reegineering (BPR) and now Business Process Management (BPM) are activities which also look at improving how a Business works. Some companies develop a target Business Architecture describing the product and/or service strategy, and the organizational, functional, process, event, information, and geographic aspects of the business environment.
Very often, based on my experience, and observations, IT processes do not have a process owner. If there are owners, sometimes they are siloed. As an example, the ITIL Incident Management process owner does not work in harmony with the ITIL Availability Management process owner, etc. Sometimes, politics, company’s mindset, or personnel agendas, prevent to do a consistent job.
On the Business side, it happens also that processes are siloed and not cross-functional. The integration between IT Processes and Business Processes is even not considered despite the fact that all Business Processes should be linked to IT Processes. The processes and activities of a Line of Business have Incidents, Problems, issues with availability etc…
The first step would be to have for the IT department a Service Manager (e.g. ITIL) to coordinate all the processes related to IT Service Management. On a parallel, the Business should also have owners for their processes.
Recently I was looking at some documentation related to the SAP ESA (Enterprise Service Oriented Architecture) and found a very interesting comment from Shai Agassi, member of the SAP Executive Board and president of the SAP Product and Technology Group (PTG). He claimed that “Chief Information Officer” function is morphing into two distinctive roles: the Chief Process Innovation Officer (CPIO), and the Chief IT Officer (CITO, to coin a new acronym). In this new model, the CPIO is in charge of innovative business processes and continuous process integration.”
All processes have definetly to be coordinated, IT or not in a consistent way. As improving processes allows to bring innovation, this new role (Chief Process Innovation Officer), would allow companies to create new synergies, between the Business and IT, considering the CPIO as a partner of LOBs, in charge of processes deisgns with the business’ network. That position would require new skills to be developed as part of the IT organization. Such a role would be the best way to create an harmony for IT/Business processes.
01 December, 2006
These days everybody is referring to a Service Catalog whatever that means. Unfortunately there is some misunderstanding between people as sometimes they are referring to SOA and sometimes to IT Service Management.
An ITSM Service Catalog describes all services that are offered by a service provider. In some cases, all services offered by the IT department of a company. The Service Catalog is part of the entire Service Level Management process. The Service Catalog describes the standard services offered, based on which agreements are made with clients. These agreements are subsequently covered in Service Level Agreements. It also becomes the basis for documenting procedures and processes in an IT organization.
Depending on the purpose the organization hopes to achieve, the service catalog may be rich in detail or simply provide a top level explanation of services. An IT department manages, maintains and supports part of the IT infrastructure of the Organization. This infrastructure consists of a large quantity of products with which services can be provided.
These services are described in the Service Catalog.
To first identify services, we have to work from the perspective of the core business purposes. Then, look at what IT offerings support those services. After the core purposes, we have to move into those supporting areas that IT also serves, such as administrative or general organizational support. The entire Service Catalog should be viewed from the customer’s perspective. Some services can be further broken down into sub services as well.
For every service a clear description and all relevant characteristics are included. Based on this a client can assess the business application and the usefulness of a service for their own organization.
After looking at services from the business perspective, we start to define each service with the following information:
-Service Name (a simple description, preferably the same name the customer would use)
-Service Description (high-level description of the service written in language customers can understand)
-Support Contact Point (Where should the customer begin an inquiry or report problems regarding the service?)
-Responsible Manager (Contact person responsible for the service)
-Customers/Users (What set of customers (specific or general) utilizes this service?)
-Detailed Specifications (Some items may not require all of these elements, but possible elements to include in specifications are):
- Inputs (hardware, software, infrastructure, customer inputs, etc.)
- Outputs (final products viewed from a customer perspective)
- Default items always included
- Optional items the customer may request or pay extra for
- Excluded items which are never included
- Service hours of availability
- Up-time and service availability goals
- Support provided
- Performance standards for the service
- Customer procedures for starting, changing or ending the service
- Charges (if appropriate)
- Data Integrity
A Service Catalog is intended for all clients of an IT department, in other words, the business unit managers and/or their representatives that want to be extensively informed about the services offered by the IT department of his company.
An SOA Service Catalog has another goal: to manage, organise and reuse services. One of the key promises of SOA is reuse on a much more granular level than one could ever hope to achieve with pure object oriented techniques, but reuse isn't something that we get for free. Particularly, reuse problems arise when others within a teamdepartmententerprise don't realise that we have already defined and/or built a particular service that they could reuse.
To achieve in some way that objective, a SOA Service Catalog needs to exist and document the basis of each service. To build such a Service Catalog is not an easy task as you will need to first define the granularity of your services (please refer to my previous post: What is a Service?) which decribes the differences between an SOA Service and an ITSM Service).
As for an ITSM Service Catalog, information has also to be identified and captured:
- Service name
- Type of service (e.g. business, application specific, data, etc)
- Service level agreements and other quality of service characteristics (e.g. performance, scalability, security, availability, etc)
- For each service operation
- Operation name
- Request/response messages input/output parameters and possible errors
- Whether the operation is idempotent
SOA Service catalogs leverage both Web services (application services (provided by reusable software components) that are typically found further down around the middle of the IT stack) and BPM to eliminate an expensive burden on business. To be effective, that service catalog must contain services in the language of the customer, must be transactional and finally flexible.
For sure both Catalogs relate one to the other but what is contained inside is quite different. The SOA Service Catalog should be considered as a Service Registry. The future will tell us how to link both catalogs once synergies between ITSM and SOA will be better documented and companies will have reach an upper level of maturity in these two domains.
23 November, 2006
Many companies have a wide range of non integrated solutions covering several aspects of IT Governance such as:
For each of these components some of them have associated processes but no real touch points between them and the visibility is quite difficult to get in terms of IT Service quality. Some companies passed certifications such as ISO 9000, ISO 27001, went through COBIT, and are ITIL based etc... But from my various observations, they do not have a consolidated or integrated view of their IT Services which would contribute to the improvement of Business IT Alignment.
Very often, top management including the CIO ask for IT to deliver Dashboards where we can have in real time indicators (KPIs) on the department performance and then be able to benchmark against competition.
Among existing solutions we have, IT Governance suites such as Mercury ITG or CA Clarity, Service Management platforms such as Peregrine Service Desk, Remedy, CA, HP, Asset management solutions, and finally Time Management product. In the system management landscape, Tivoli, CA Unicenter, and lots of various monitor solutions to manage networks. Fiinally, Enterprise Architecure is often covered by companies such as Telelogic (Popkin), Casewise, Metis solutions etc…
My experience would be to claim that first we need to re-engineer the process, have integrated flows between domains in order ro be able deliver these dashboards, finally avoid duplicated activities within an IT Department.
As no vendors today is able to deliver such an “IT ERP” (but probably HP, IBM and CA will be able to deliver this but nor before a couple of years…), an alternative would be to consider services around these platforms and then from a portal, orchestrate those services, provide results in various dashboards. Obviously if we had an integrated platform, that would be easier.
For the time being, mash-up applications are probably the only way to produce an IT ERP.
09 November, 2006
Examining innovative Enterprise Architecture Methodologies, Getting SOA Experience and Enhancing Information System Agility to meet Organizat. Needs
Examining innovative Enterprise Architecture Methodologies, Getting SOA Experience and Enhancing Information System Agility to meet Organizational Needs
Event Date: 27-28 November 2006
Location: Dorint Sofitel Amsterdam Airport, Netherlands
09.55 Case Study
Presentation of Processes and Tools: Enterprise Architecture, Service Management and IT Governance Frameworks
• XXXXX's vision of the components: IT Governance frameworks
(e.g.ITIL, CMMi, TOGAF, Cobit, ISO)
• The standards for Research and Innovation, Enterprise Architecture,
Service Management and their relationships
• Defining the key governance processes and gaps
• Selecting the tools to support the frameworks
• Integrating Enterprise Architecture as a key governance enabler
• Making it all work together
07 November, 2006
The business team then evaluates the prioritized, ranked projects to determine the proper portfolio mix and whether to accept the recent request.
Project Portfolio Management is:
• A categorization model
• A common language for business and IT to …
• Support Business strategy
• Organize investments
• Evaluate and prioritize IT projects
• Govern and manage applications portfolio
• Decide when and how to make changes (opportunities)
• Understand what can and can not be changed
• Provide real-time visibility into resources, budgets, costs, programs,
projects, and overall IT demand
• A hedge
• “What if” scenarios enable us to analyze
the portfolio and assess the business
contribution of each proposal, project,
or application to the entire portfolio
• Triggers, Thresholds
The Enterprise Architecture steering committee should be part of this governance process and be able to measure the impact at various level of the architecture:
- What is in the impact in terms of Business Procee
- What is the impact at the information level
- What is the impact at the application level
- And finally what is the impact on the technology
Assuming that a company has an Enterprise Architecture in place and an associated governance, the PPM process should be linked to the first one.
None of the existing solutions related to PPM have considered yet this type of integration. On one side we do have PPM tools such as Mercury ITG (now HP), CA Clarity Niku and on the other side EA platforms such as Mega, Casewise, and Telelogic (Doors can be considered as some sort of Demand/Requirement Management solution but can not be considered as a PPM) among others.
I’m still wondering why a company such as HP has not yet been considering an EA tool integrated with their future PPM product, or even IBM which has a PPM product with rationale but no EA solution neither.
There is a high change that the next wave of acquisition after Service Management and SOA platforms will be Enterprise Architecture tools as this would make sense to deliver a full IT ERP.
25 October, 2006
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.
- 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.
24 October, 2006
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
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
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)
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
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
- 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
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
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.
27 September, 2006
I have found the following paragraph a little bit exaggerated…
"Probably the major development, over the course of the summer, is subtler. All of the software/infrastructure vendors are continuing to put a lot of marketing cycles into promoting Service Oriented Architecture (SOA). At the same time, there has been a growing recognition that SOA, without BPM, doesn't mean much. You don't do SOA just as an exercise in technology; you do SOA to provide better support for business processes, which you define in BPM. This is the clear message in all IBM's WebSphere advertising and it is increasingly the common theme of all of the major vendors who are promoting the move to SOA. Thus, increasingly, the attention that was focused on BPM is becoming mixed with the SOA marketing effort."
Even if SOA can be (or should be...) coupled to BPM initiatives, there are many situations where companies implement SOA for other reasons:
- Composite applications
- Portal integration
- Information Hub
- Migration from “old” client server applications to new architecture models
- Mash-up applications
In fact, software vendors simply try to sell at the same time BPMs with the underlying technology...and all the associated professional services…
There are cases where SOA is justified only by the above mentioned reasons.
26 September, 2006
According to ITIL best practice recommendations, the CMDB should provide accurate information on the configuration of IT assets and their documentation in a way that will support all the other service management processes. For 70% of the organizations polled online during Tertio's research, the perceived benefits that results from implementation of a CMDB is expected to be an improved and coordinated picture of the application infrastructure, and the overall better management of IT assets.
Many companies who deployed Configuration Management have associated this process to the Asset/Inventory Management process/systems for the following reasons:
- Desktop Inventory is often based on inventory existing solutions
- Server Inventory is usually done with System Management solutions such as Tivoli, CA Unicenter, BMC Patrol, etc…
However, there is one activity missing from a Configuration Management view: the building of relationships based on Cis (configuration Items).
To be successful at Business Service Management, companies first should map applications and Services. This is probably the only way to know which IT failure is mucking up Business Services.
To address the issues with the Configuration Management process, companies should find a solution which would avoid creating manually the relationships between the various CIs (Configuration Items) which are identified with the various Inventory tools.
Companies need tools that collect systems configuration data, decode packets and watch kernel I/O to determine application dependencies. These are not service, performance or status monitors rather, they map all the servers, systems, applications, processes, services, users and sometimes even network devices to decipher what applications depend on, and what depends on them. This mapping also makes diagnostic, capacity and Service Management application delivery easier.
These tools should be able to:
- Improve the quality of data in a CMDB
- Be in real-time
- Populate data into the Service Desk
- Avoid to maintain manually the systems
- Keep in real time the relationship between CIs
- Improve all ITIL processes, but specifically Incident Management and Change Management
- Provide Change Impact Analysis features
- Track people changing the infrastructure into production
- Deliver Business Services views
- Map ITIL processes
- Integrate smoothly with both the Service Desk and the System Management solution
- Replicate these relationships into Business Service Management solutions
- Send alerts to the System Management console when for example a change on the Infrastructure is done in production
- Replicate these relationships with Enterprise Architecture platforms such as Mega, Troux technologies, Casewise, Popkin, etc..
- Provide out of the box connectors
- Cope with the long term strategy around Service Management and Enterprise Architecture
There used to be more that 10 to 15 vendors in that space, half of them have been acquired by companies such as Mercury, IBM, Symantec, BMC and others who integrated these tools into their Service Management products.
Companies haven’t yet considered implementing such solutions but this is slowly starting. Auto discovery tools are a must!
23 September, 2006
QA standards overview and (company) implementation choices and benefits
The first part of the presentation will introduce QA standards such as :
- Service Management (ITIL, ISO/IEC 20000-1/-2:2005)
- Quality Management ISO 9001,
- Security Management ISO 2700
The second part will present (company) implementation choices and benefits
Place: CICG CICG,
17 rue de Varembé,
CH - 1211 Geneva 20
Room: Conf. Room 7+8
Starting date: 27-Sep-2006 11:00
Primary Authors: Mr. THORN, Serge (Director IT Research & Innovation)
22 September, 2006
Vendors (mostly help desk solutions were selling in some ways, improvement with the OGC processes by promoting system management solutions). Years after years, ITIL became famous, most vendors started to re-brand their offering and solutions, which became "ITIL compatible" (which does no mean anything by the way...). Companies such as HP, IBM, CA, SUN, and many others started to sell the concepts of best practices, adopting IIL as the way forward.
These days, many people have now jumped on the bandwagon and everyone is referring to ITIL. All software and IT consulting companies pretends mastering Service Management. Yesterday EMC even positioned themselves as a new Service Management company. ITIL is now a given and every single It Data Center is now embracing the framework which has become an IT Governance pillar.
But how can we improve the famous IT Business alignment, as Service Management contributes to this but is not as visible as expected despite what is claimed by the IT industry!
Enterprise Architecture is becoming a new standard as already described in my other article “Why is Enterprise Architecture becoming the “next big thing? ”, but people will be looking at a framework in the same way they looked at a framework for Service Management.
After several months of investigation, studying the various existing Enterprise Architecture frameworks such as: META (Gartner), Zachman, TEAF, FEAF, DODAF, IEEE Std 1471, ISO RM ODP, NASCIO, IBM ESS, I came to the conclusion that TOGAF 8.1 was the most evolved and appropriate framework for a company which is process oriented. Other frameworks are sometimes referring to process, but not as detailed as the one from the Open Group.
Developed by the Open Group in 1995, The Open Group Architecture Framework (TOGAF) provides the most comprehensive methodology for producing architecture deliverables. With its most recent version (version 8), also known as TOGAF Enterprise Edition — TOGAF’s Architecture Development Method (ADM) was quite substantially expanded beyond technology architecture to include business architecture, information architecture, and application architecture
It is an open framework, highly customizable. The core components of TOGAF are its Architecture Development Method (ADM) and the TOGAF Foundation Architecture.
The ADM defines a process for developing and maintaining the organization's Enterprise Architecture, and for implementing the architecture through a planned program of work
It is non-prescriptive about how to build the models that represent the architecture, and supports all standard modelling technologies, such as the Unified Modelling Language (UML), Business Process Modelling Notation (BPMN), and Integrated Computer-Aided Manufacturing (ICAM), Definition (IDEF).
The Foundation Architecture describes an Enterprise Continuum through which the developing architecture progresses from the general (foundation) to the organization-specific
What makes TOGAF popular is that it is a definitive and proven step-by-step method for developing and maintaining Enterprise Architecture. It covers the four principal architecture domains of business, information systems (application and data), and technology infrastructure, and focuses strongly on the need for architecture to support business objectives and requirements.
It also takes into account establishing the goals and objectives of the Enterprise architecture effort itself, guiding users on determining how much of the enterprise is needed to model to realize significant gains, and the realities of getting buy-in from throughout the organization.
20 September, 2006
- Alignment with the company’s Business Model and Strategy
- Enable business changes, technologically based business opportunities
- Improved interoperability and integration
- Enabled agility
- Reduced costs
- Better assets utilization
- Reduced time to market
Now when you look at SOA projects in some companies, very often they run some sort of submarine programs. In other words, because of the difficulty to sell to the business such technological projects, these projects are considered as foundation for future business projects and are done in the shade. ROI on SOA then becomes potentially measurable after a first business project and users are rarely aware that the underlying architecture has fundamentally changed.
But why is an IT department considering going for SOA? Agility…yeahhh for sure..But why? It appears to me that very rarely SOA is based on a real case study.
I have identified several types of reasons why we should go for SOA:
- A BPM program or initiative has been identified
- There is a need to build new composite applications in an easy way
- A company’s portal needs to integrate easily new applications, portlets, or services
- There is a need to migrate old applications (e.g. traditional Client server applications) to new layered and modern applications
- To provide integration between companies (B2B)
Some companies have SOA programs in place…but are they able to justify the investment if none of these requirements have been documented?
19 September, 2006
Among these tools, we could select solutions such as Holosofx (now IBM), Proforma and Aris from IDS Sheer. There was no links between these tools and the various workflow engines such as FileNet, IBM Flowmark, Staffware (now TIBCO) among others…
Interesting enough, some of these tools evolved towards Enterprise Architecture, considering Business Modeling as an activity in Business Architecture. The latest being a layer an Enterprise Architecture Framework. Other Enterprise Architecture modeling tools such as Popkin Software (now Telerate), Mega, Casewise and Proforma have also evolved towards Enterprise Architecture and provide Business modeling with various notations types such as BPMN, UML or proprietary ones.
For a couple of years now, everyone is overloaded with vendors’ information related to BPM (Business Process Management). Maybe BPM is only a re-branding of BPR., but then everyone claims (at least vendors and IT Analysis consulting companies) that BPM brings business agility and flexibility, minimize IT costs in terms of reuse, time to market, specifically when built on top of SOA (Service Oriented Architecture). BPMs (BPM Suites) are solutions which can include different layers such as modeling, simulation, orchestration, rules management, and integration.
Processes can generally be captures in the modeling layer from the BPMs and be improved in an iterative way, through simulation and real time monitoring.
The reality is that many companies’ ends up with two sets of modeling tools which does rarely connect one to the other. Business modeling on the business side realized with either BPR or Enterprise Architecture suites are not reusable by BPMs. Some standards are available to exchange models such as XMI, but not all vendors have applied yet these features.
The following questions remains:
- Should we use two set of tools?
- Should we use one as the master and export to the BPMs or the other way around?
- Should we find a single tool or solution which connects to the BPMs/orchestration suite (eg. Telerate and IDS Sheer have already announced integration between their modeling suite and Business automation/orchestration platforms such as the Oracle Fusion middleware. Other probably to come...)?
The conclusion is that the market is still immature and many companies jumping into BPM/SOA will have to consider with caution the way they will model their Business processes, in order to be able to measure business impacts and automate at the same time their Business Processes.
12 September, 2006
Service Management is usually supported by Service Desk solutions such as Peregrine, Remedy, CA and many others ITSM suites. PPM is usually supported by companies which started with project management solutions and extended the capabilities to Portfolio Management such as Primavera, PlanView, Prosight, etc.. Some companies also have time sheet solutions based or not on Microsoft Project. Demand Management solutions have been until now isolated from PPM and usually are also standalone solutions such as IBM RequisitePro, Mercury and Telerate DOORS. Enterprise Solutions can be found from various vendors such as Mega, Troux technologies, Telerate and others.
We can observe trend where solutions start to become integrated through the M&A wave. CA bought Niku, HP acquired both Peregrine and Mercury, but still. many companies have best of breed solutions which are not integrated and do not provide integrated views on the health of an IT department.
CIOs and other Managers would like to see integrated dashboards to find out where issues are and what actions have been taken on.
Two things need to be considered for the time being:
- to develop in house solutions to retrieve information coming from these various solutions in order to have a single coherent and consistent view of the IT department and deliver the expected visibility to the business users
- to exchange information between these solutions:
o Demand management probably linked to Change Management
o Enterprise Architecture linked to PPM
o PPM linked to Time Management
o Change Management linked to Release Management solutions (e.g. desktop, business solutions such as ERP, CRM)
o Enterprise Architecture linked to Change Management
And probably much other integration…
Everything would be based on the pillars of the company’s IT Governance framework. As an example…how would a company using Six Sigma or CMMi, integrate with a Service Management solution?
May be in 3 to 5 years time…vendors will understand that we need integrated solutions and acquire the missing modules for a full IT Governance solution. Today, best of breed remains the only possibility…
05 September, 2006
Many companies after having selected a set of IT Governance pillars are looking for solutions to support them and deliver several types of dashboard to either the Corporate and/or IT Management. But, what are these pillars? Some IT department considers one or more components as IT Governance, some other cumulates several components.
IT Managers very often refer to ITIL, or COBIT, or Balance Scorecards or any other frameworks which will improve efficiency and give some visibility to the business.
Let me briefly describe first what I’m considering as components of an IT Governance, but prior to that, I would like to refer to a very simple definition from the Harvard Business School:
“We define IT Governance as specifying the decision rights and accountability framework to encourage desirable behavior in IT”
Fundamentally, IT Governance is concerned about two main things: IT’s delivery of value to the business and mitigation of IT risks.
The components of IT Governance can or should include at least:
- Aligning IT strategy with the business strategy
- Quality Management
- Strategic IT Planning
- Enterprise Architecture
- Project and Portfolio Management (PPM)
- Service Management
- Audit Management
- Security Management
- Risk Management
- Performance Measurement
The list is not exhaustive and could obviously be completed.
I tried to find if there were any IT Governance frameworks available in the market and always ended with specific frameworks related to the components of this IT Governance. ITIL, COBIT, ISO 9000, CMMi and others… Now, from there, where do I start?
What we need is a Framework of Frameworks… where I know where to start, where to pursue, where to end…all of that in an iterative mode..
I recently discovered The Calder-Moir IT Governance Framework http://www.itgovernance.co.uk/page.framework which looks like as a good initiative in terms of standards framing. This has been developed by IT Governance Limited.
Until today, to my knowledge, no single organization has provided a full picture of how to manage IT Governance. Is this framework something which should be seriously be considered or only a way to sell consultancy?
01 September, 2006
IThese days, everyone is referring to ITIL as being a pillar of IT Governance but without really understanding if improvement has to be done at the IT operational level or somewhere else… Some people also imagine that Service Management is a way to improve what everyone loves to refer to: “IT Business Alignment”.. My belief is that in can contribute in some way, but is not the primary goal as an objective.
For sure Service Management is a component of IT Governance but other components are worth being looking at such as Enterprise Architecture.
An Enterprise Architecture consists of the vision, principles, standards and processes that guide the purchase, design and deployment of technology within an enterprise. An Enterprise Architecture describes the interrelationships between business processes, information, applications and underlying infrastructure for that enterprise, and provides best practices for technology purchase, design and deployment.
Enterprise Architecture structures and processes govern adherence to an organization’s technology strategy and provide a managed environment for the introduction of new technology.
The Key Benefits and Value proposition can be
- Alignment with the company’s Business Model and Strategy
- Enable business changes, technologically based business opportunities
- Make easier the introduction of new technologies
- Allow standardization
- Information (or data) consolidation
- Reduce enterprise/application integration complexity
- Facilitate outsourcing if required
- Better assets utilization
- Better assess the impact of changes
- Reduced time to market
Coming back to IT Business Alignment, the objectives should be:
- Better understand the company business model (current and future)
- Understand the relationship between the business model and the current and future IT architectures
- Reposition IT such that it is aligned with business strategy, and be able to communicate that alignment to the business community
Build roadmaps showing how IT can create credible solutions that align with the business strategy
For all these reasons. Enterprise Architecture should be considered as a top priority level for IT Departments who wants to be real partners to the business.
29 August, 2006
Configuration Management which is one of the main ITIL processes requires the use of support tools, which include a CMDB. Physical and electronic libraries should be set up parallel to the CMDB to hold definitive copies of software and documentation.
Until now, several vendors have provided through their Service Desk offering, and out of the box CMDB which in some case could be altered. Among these vendors we can find, BMC-Remedy, HP, Peregrine (now HP…), Axios systems, Computer Associates, Mercury (now HP…), IBM, and many others.
Last April, some vendors like CA, BMC, IBM, and Fujitsu announced they would work toward developing "an industry standard for federating and accessing IT information" that would ideally integrate communication between disparate configuration management databases.
CMDBs have become one of central elements of enterprise IT management, so a standards-based approach to this critical functionality is necessary and valuable.
Looking at SOA and the way we define composite applications and services, we definitely need to build the latest on the top of existing IT Infrastructure, software and hardware. In other words, a CMDB could also be used to manage the catalogue of SOA Services!
I would be tempted to think that in the next 2 years, a CMDB will be a modular component, usable by either Service Management solutions, and/or SOA Governance products. A CMDB could become a sort of “plugin” available from various vendors with sets of APIs, and why not web services.
SOAs are distributed computing plans where companies often situate Web services and reuse code and other assets to create efficiencies. Vendors like IBM, Microsoft, BEA, Oracle, and Mercury are creating SOA infrastructure platforms to speed information exchange between different computing machines. A few months ago, prior to HP acquisition, Mercury acquired a SOA company named Systinet. This acquisition strengthened Mercury's position in the high growth SOA (Service-Oriented Architecture) market by giving the company leading SOA governance and lifecycle management products.
An integration point should be between the SOA metadata repositories and a configuration management database (CMDB) to manage the lifecycle through to operations. If HP considers the range of acquisition they recently did with Peregrine, Mercury...and Systinet…there would be a high probability, this integration occurs!
Another observation on this future integration is potentially visible with IBM. IBM released recently a CMDB titled Tivoli CCMDB, and also launched a management and security solutions for managing SOA based applications, IBM launched last April IT Service Management platform.
The IBM IT Service Management platform manages SOA based composite applications. It is supposed to offer an approach to defining a framework and solutions for IT service management, including extending self-managing autonomic computing to IT services.
“Tivoli CCMDB uses a Federated model that allows it to be implemented on top of an existing sources of IT data, and serves as an authoritative source of data for configuration items, their relationships, so that when a change needs to be made to any of the IT components, one can understand the impact of that change on other related components. IBM's ITSM platform along with, IBM Tivoli security and compliance products like Tivoli Access Manager and Tivoli Federated Identity Manager delivers a complete end-to-end solution for the "manage", "secure" and "compliance" of distributed SOA applications.”
IBM and HP are two companies which will probably compete in both IT Service Management and SOA. They probably understood the synergy between the two worlds, and we can predict a future new generation of CMDBs, modular, accessible from web services, and used for several companies needs: Service Management and SOA Governance.
28 August, 2006
On the other side, we have SOA, Service Oriented Architecture, which is often associated to BPM, Business process Management. A Business process is a set of automated or non-automated activities, or tasks, exchanging data, where we define flows, and assign roles. An SOA enable a BPM initiative by associating services to task. These services are generally speaking IT components launched by a set of specific SOA technologies such as SOAP, XML, HTTP, WSDL, etc.
When comparing Services in Service Management terms and Services in SOA terms, there is very often some sort of confusion.
ITIL is focused on the provision of services by the IT department to the customer/user. Now these services which are used by the user/customer can take the form of applications that they use (e.g. email services, components of HR systems, ERP and financial systems) or other services which are utilized, such as internet access, printing services, etc. SLAs are then determined for each particular service. Now ITIL encourages the IT department to view these services and determine the underlying technologies which are required to provision these services. For example, UNIX or Windows Servers, Network equipment, Printers, etc. and to identify each outside party that may then provide these underlying technologies. OLA and underpinning contracts are then used to ensure that these parties perform their duties so that the IT department can then fulfil their SLAs.
A SOA Service is defined as a unit of work to be performed on behalf of some computing entity, such as a human user or another program. SOA defines how two computing entities, such as programs, interact in such a way as to enable one entity to perform a unit of work on behalf of another entity. Service interactions are defined using a description language. Each interaction is self-contained and loosely coupled, so that each interaction is independent of any other interaction.
We observe that the SOA Service is much more granular that an IT Service and finally, the latest is maybe the aggregation of several SOA Services…
In other words, SOA and Service Management are not identical in terms of Services definition and this creates lots of confusion in the IT Community. Service Management can be utilized to manage an SOA implementation or solution or the ITIL processes could handle SOA Services as software/hardware components, but Service Management is not a subset of SOA.
24 August, 2006
Jeudi 28 septembre 2006
Auditorium de la Fédération des Entreprises Romandes - Genève
13h30 – 14h15 Retour d’expérience
23 August, 2006
Facilitator Serono International www.serono.com
TOGAF has been evolved continuously within The Open Group's Architecture Forum over the last twelve years, drawing on the knowledge and experience of The Open Group members who are themselves practising Architects working for a wide range of enterprises around the world.
14.15 Enterprise Architecture (French)
22 August, 2006
Raffles Le Montreux Palace, Montreux (Switzerland)
Discover the real benefit of ITIL
How to develop passion for high performance services