Mandatory Elements Required to Create a TCO Assessment



Total Cost of Ownership

Total Cost of Ownership

Regardless of the objective of the analysis, several mandatory elements must be included for the analysis to qualify as a Gartner TCO:
• Identify the domain or activity for which an annual TCO is required (for example, distributed computing, telecommunications or data center), or to make a specific decision, such as, “Will server consolidation really save us money?”
• Develop a chart of accounts, which is a list of cost elements that refers to TCO as
defined above. For IT costs, this must include or evaluate the following:
• Direct cost elements relating to assets or activities that are relevant to the analysis;
for example:
• Client, server, storage and all peripheral hardware costs
• Software and related support costs
• Maintenance and development costs
• Networking and communications costs
• IT operations and support costs
• Associated indirect cost elements — for example, labor costs associated with the end user’s use of an asset or activity, and any subsequent downtime involved.
• Ensure that the chart of accounts contains cost elements that satisfy the TCO definition’s criteria for “holistic view” and “enterprise boundaries” — that is, taking a wider view of costs than normally occurs. Rather than simply being concerned about identifying and listing the costs within a specific function or department, the chart of accounts must also contain cost elements or cost categories that could be affected by activities or changes in the domain. For example, the chart of accounts for a help desk TCO may include cost elements outside of IT operations or IT support. Limiting the chart of accounts to cost elements only contained within IT operations is misleading, because help desk users incur a cost in the form of time spent and, thus, opportunity lost. Indirect costs may be associated with other departmental budgets, but they are still part of a properly constructed TCO. It’s easy to turn a blind eye to such costs — for example, assuming that they’re too small to be relevant, while ignoring the multiplication factor caused by the many individuals who are involved.
• Review the chart of accounts to ensure that all of its elements represent an annualized view of the TCO in question. The chart of accounts should contain details on critical affecting factors (such as depreciation periods) because these will significantly affect any annualized view.
• Review all chart-of-accounts elements to ensure that critical cost elements have been included and don’t overlap, thus avoiding double counting.
• Collect and validate information regarding the costs and other data required to populate the chart of accounts. Use the enterprise’s financial management system, asset management system and HR records to detail unit costs, and use survey questionnaires to establish people’s use of time.
• Amortize all cost elements in the chart of accounts during a specified time period (such as annual, quarterly and so on). For example, a server with a three-year depreciation period would be included in the chart of accounts as one-third of the total server cost.



Service Level Agreement – a HIAL implementation proposal for eHealth Ontario



, , , ,

eHealth Ontario

eHealth Ontario

The SLA is a formal document outlining a service commitment provided by an IT service provider to one or more customers. The Service Level Management mission statement is to “plan, coordinate, negotiate, report and manage the quality of IT services at acceptable cost”.

The scope of the SLA project is to implement an enterprise framework that adapts to changing business priorities and service levels, define clear goals to shape the service offered by the provider, and avoid the back and forth associated with service level disagreements.

SLA benefits include open communication and the ability to manage the customers’ expectations. IT organizations also benefit from a clearer picture of what the users need, the ability to balance and adjust their resources to meet those expectations, as well as explicitly detail the costs associated with any given level of service.

For more details check the following attached PDF document:


SOA problems


enterprise system spaghettiThe common and most important problem of enterprise IT architecture is to integrate siloed applications, inflexible data structures and technology-specific platforms. SOA is technology independent. Thus there are several possibilities to implement a service that can be accessed by a service consumer via the service bus.

The structure of the legacy systems may also be a problem as they are often siloed applications and separated from other applications.

Unpredictable twists and turns in an ongoing project to suppliers, customers or the environment are not an exception but the norm. These risks are well-known, because they frequently occur in many ongoing projects, as well as in the execution phase. Nevertheless, they often do not get a close attention. Problems are then blandished as challenges, but they are occurred risks. Only if those risks are known, we can handle them.

Even though the principle of the separation of concerns is important for creating reusable software and realizing an SOA, it is often violated for many reasons. There are internal and external reasons. An internal reason is the amount of work. It takes time to create software that meets the requirement of separation. Some try to avoid the additional effort and sloppy solutions win over sustainable solutions. The disadvantages of this behavior will appear in the future and many people repress them in the present. An external factor is the behavior of IT vendors that want to lock the business logic of their customers to their proprietary technology. The separation of concerns may reduce their profit, so an organization should not blindly trust on their vendors’ technological recommendations. Their greed will prevail over technical advisable solutions. Companies should use open standards to remain independent.

Big IT projects usually fail because too many participants operate over a long period of time on a project and everyone works on his hidden agenda. Starke and Tilkov, SOA experts, suggest determining a strategic direction and a fast implementation of smaller projects. Feedback loops of the projects’ experience lead to an adjustment of the strategic direction. They emphasize particularly a solid governance.

Many SOA projects were not as successful as the SOA infrastructure vendors promised. The technical requirements are not the problem. These are solved perfectly. The main problem is a missing methodical approach to identify the business services that exist in a company.

The service oriented approach is not a pure IT issue. It means that the business processes need to be designed service-oriented. That is the main problem of many SOA efforts. The entire company has to get involved in this new way of thinking and abandon established habits. It is clear that this is not a piece of cake. When an SOA project fails, it is most probably not in the technology but in the communication and the lack of willingness to compromise. [1851-FOM_ILD_Arbeitspapier_Bd27_Online_12_12_18-01_01.pdf]

Some enterprise architecture resources


Some enterprise architecture resources :

Enterprise Architecture at Work

Enterprise Architect User Guide

Doing Enterprise Architecture – Enabling the agile institution

Service Oriented Architecture for Dummies

Overview of Enterprise Data Architetcure

National Association of State Chief Information Officers – Enterprise Architecture

MIT Enterprise Architecture Guide

Everyday enterprise architecture-Sensemaking, strategy, structures and solutions

Enterprise Architecture Whitepaper-1-23-03

Enterprise Architecture Tool Selection Guide v6.3

Enterprise architecture modelling-the issue of integration

Typical SOA Implementation Challenges

SOA CartoonMany of us have been introduced to SOA via webinars, articles and books published by SOA vendors. The promises made bythe SOA evangelists seem easy to achieve and are every CTO’s dream. But it is during the implementation phase that reality surfaces. Each SOA promise is in reality an enormous challenge. Let us have a quick look at some of the common challenges we have come across, while implementing SOA, over the recent past:

Multi-layered complex architecture makes it tough to isolate defects.
Agility – Enabling faster change leads to increase in integration and regression testing.
Integrated Systems – More points of failure result in more defects.
More Reusability – More problems in security and performance.
Managing people across geographies in disparate teams.
Heterogeneous technologies – Expensive to test, and manage a wide variety of systems.
Testing processes that span across multiple systems create complex test data needs.

Some of the challenges SOA brings for the testing teams are that they have to learn new technologies, processes and new tools that are being used. Many testing teams often check if they can continue to use classical tools and processes in the new SOA environment. Once they begin SOA testing, they quickly realize that this can’t be done. Let’s look at some of the reasons and questions that lead to this realization:

Modern Tool Requirements

SOA has a unique architectural ecology.
• Can classical tools test non-UI components?
• Can these tools cope up with subscriptions to brokers?
• Can they interpret messages that flow across an ESB?

SOA has its own set of unique protocols.
• Can the current automation tools handle protocols such as SOAP, WS-Security etc.?
• Can classical tools take you through a web of component invocations for defect isolation?

Methodology Changes
• A new architecture brings the need for a new approach. Current black-box lifecycle processes and tools cannot cope with the sudden need for deep grey box testing. For example, we need to test the UI and the components behind it.
• SOA lifecycles are agile and iterative. This in turn increases the importance of automated regression testing. How does one enable continuous integration testing where manual testing is impossible and classical tools do not work?

End To End Business Process Testing
• Can current tools handle orchestration of multiple tools that span across technologies? For example: UI automation, middle ware testing, service testing and database querying.
• End-to-end process testing can create some complex TDM requirements that non-SOA monolithic systems would not require.

Restricted Access Systems
• Per – use SaaS (Software as a Service) systems can drive up the cost of regression testing.
• Some systems such as mainframes may not be easily available or accessible for testing.

Information was collected and provided by Infosys

Some challenges when automating UI and Web Services testing at eHealth


comix– Reuse, redesign, and replacement of test component parts (SOAPUI scripts) is very difficult in SOA testing when dealing with multiple technologies and standards like HL7V2 MLLP, HL7 V3 Layered design, IHE – XDS, SOAP, SAML and many other technologies and protocols used when accessing IF – HIAL.
– Loosely coupled collections of data and functions residing on multiple internal or external machines. The large set of technologies as mentioned before and the loosely coupled collection of data will define and render each test environment as unique. For instance the Development DIT and Functional testing environment ITE1 (aka FIT) are going to be different due to the large number of databases, servers and code versions deployed in the specific environments.
– The advantage of the reusable artifacts (services) that are accessed through well-defined, platform independent, interfaces named contracts (WSDL) are true only for the final product running in the Production environment and does comply with the business specifications mentioned in the contract. In the lower stages of the software development and testing life cycle the contract is not enforced and varies significantly from one environment to another.
– Because SOA applications are composed of loosely coupled, business-level services, distributed over a network, we must test the application from the following perspectives: end-to-end, service-by-service and interface-by-interface. There is no magical bullet that targets all the functions in one shot.
– We need to trust SOA services in the following areas, but we may not control the following testing that can’t be automated. Functionality which includes API – Application Programming Interface and Interoperability plus Integration. Also Publishing, Finding and Data Binding, Security and Performance are difficult if not impossible to automate.
– The overall functionality of SOA applications should be easier to test. That is true only if we, or someone we trust, thoroughly test the application’s components (services) before we assemble them together to create the application. Having said that, starting with lower-defect components typically means a smoother testing process but SOA applications generally have an increased number of: APIs (one for each service), communication paths between those services, there is now an increased level of integration and interoperability testing that must be performed. Considering all these aspects who is responsible for this testing? The service provider? The service requester? Both? Someone else? How do we establish trust?

Defining a Service Oriented Architecture (SOA) Mindset: Big SOA or Small SOA


How would you define your team’s Service Oriented Architecture (SOA) mindset and the value you derive from Big SOA or Small SOA approaches?
Service oriented architecture (SOA) represents a significant paradigm shift in application development techniques. SOA is a software design discipline in which application and infrastructure functionality are implemented as shared, reusable services. Each service implements a discrete task, and any application that needs to perform the task uses the shared service to do so. Teams create applications by assembling the appropriate services. After teams implement business functionality as services, an organization, their partners, and their customers should be able to mix and match these services and rapidly create new applications to support changing business requirements.

Because SOA presents an architectural goal state at odds with a long-lived legacy IT portfolio, SOA is a long-term architectural journey, and not a short-term implementation initiative. Because APIs interconnect business capabilities inside and outside the organization, APIs can provide a platform for business stakeholders sponsoring enterprise IT renewal and pragmatic business execution.

The last ten years of SOA promotion, implementation, and evaluation have cultivated two distinct ways to approach SOA; Big SOA Mindset and Small SOA Mindset.

Big SOA Mindset

Big SOA requires organizations to scale adoption across multiple consumers by establishing a shared understanding of business and technical domains. Each service is part of a bigger picture, and a well-designed service plugs into existing business processes and supports defined business requirements. Effective service adoption within an enterprise require significant planning, coordination, and governance. Organizations must be cautious not to let a Big SOA initiative fail due to analysis paralysis or inter-enterprise feudal fiefdoms.

Big SOA initiatives focus on enterprise governance processes, enterprise-wide re-use, and portfolio consolidation. Achieving these big goals requires structurally changing design-time processes and overcoming significant cultural bias that lead to inhibiting design, accounting, control, and operational ramifications. Traditional Big SOA initiatives can succeed, but only if top-level organizational support (e.g. C-level) overcomes organizational inertia and project teams bridge silos and operate as one team.

When tackling Big SOA, teams need to find an effective entry point. Some teams start with an IT-driven initiative or slipstream on important business-driven transformation initiatives.

An IT-driven Big SOA approach can be very effective when focusing on building shared infrastructure services, such as security, identity, auditing, monitoring, and cloud management. These efforts can deliver rapid returns on investment, and they don’t require extensive collaboration with the business units for success. On the other hand, this approach delays engaging the business and may provide minimal return on investment (ROI) recognition unless incorporated into more visible risk management, cyber-security, or customer experience initiatives.

A business-driven Big SOA approach is often triggered by a top-down imperative to redesign business processes and/or the customer experience. By design, these business transformation efforts must be highly coordinated across IT and the various business units. When considering pursuing Big SOA, slipstream service portfolio investment behind funded business projects.

A Big SOA initiative is not a short quarterly project but a multi-year program containing several roadmap steps. To maximize and accelerate success, team embarking on Big SOA should incorporate a structured transformation program into their journey:

Set up a cross-functional SOA Working Group
Develop a SOA Adoption Plan
Define Target Service Portfolio
Develop a Business Case
Plan and Fund Development of SOA Infrastructure
Establish New Roles
Plan Training and Mentoring for Staff
Develop Corporate Policies, Guidelines, and Best Practices
Institute SOA Governance Processes
Establish New Incentives that Reward Good Behavior
Identify Candidate Projects
Establish Priorities
Reassess Your Software Development LifeCycle (SDLC)

Many teams embarking on SOA do not have the authority, span of control, or influence to implement required Big SOA activities. With Big SOA success unobtainable in many organizations, team members who want to ‘do SOA’ and demonstrate business value often focus on small SOA.

Small SOA Mindset

A Small SOA approach implements SOA principles on a project-by-project basis. This approach incurs less risk, but produces a smaller return. Typically there’s limited coordination across projects, and Small SOA doesn’t require as much cultural and political unrest. Using this process, the organization can slowly build a portfolio of services, but with limited coordination, the services are less likely to be reusable.

Small SOA initiatives often focus on run-time environment concerns instead of design-time concerns. Popular run-time environment concerns include enabling flexible communication styles, interaction patterns, and mediation mechanisms that facilitate integration and promote loose coupling. Example communication styles include synchronous, asynchronous, one-way, and request response messaging. Commonly supported interaction patterns include peer-to-peer, brokered delivery, hub-and-spoke, publish/subscribe, and orchestrated workflow, which are used to bridge the gap between consumer-provider availability, reliability, and topology.

Mediation mechanisms reduce the need to provide symmetric messaging platforms where both consumer and provider communicate using the same protocol, message format, and communication style. Mediation mechanisms also encapsulate implementation details related to location, versioning, and identity domain.

Adopting an IT-driven Small SOA approach requires a cautious approach to not let the effort focus exclusively on technology rather than design, culture, and IT goals. Successful IT-driven Small SOA teams promote consumer adoption stories, track service subscribers, and publicize usage growth.

A business-driven Small SOA approach can result in compelling singular success stories, which will encourage SOA adoption. However, business asset re-use is doubtful without cross-team collaboration and promotion. Uncoordinated and ungoverned project-by-project efforts can generate a chaotic situation resulting in little or no reuse. How many of your services are shared, and how many services simply facilitate point-to-point integration?