Measuring Performance of Enterprise Architecture

Enterprise Architecture is viewed as an important function in IT Governance and it plays a vital role in aligning IT with the Business. This function is expected to define the technical direction and to ensure application of principles of Architecture to the design and maintenance of IT systems, which in turn should be in alignment with the business vision, mission and strategies and the role that the IT within the organization is expected to play. While the support for commitment and funding is important, it is also important that the EA function consider the following(not exhaustive) to be successful:

• Alignment with the business strategy and the culture of the organization, 
• Actively involve in projects to ensure that the principles of design and evolution are adhered to and ensure the continued focus on the business requirements.
• Offer technical consultancy for all the business and IT functions both internal and external. 
• Acting as a gate for all decisions impacting the design & evolution architecture. 

IT Governance views EA as the hub of the IT wheel with linkages with various processes, components and goals of the enterprise and some of such key and enabling links are:

• Promoting and enabling Business Agility
• Providing standards, policies and principles for the IT Project, Program and Portfolio management function
• Guides and enables cost management and consolidation
• Facilitates cost-effective, scalable integration of various IT systems
• Supports IT Governance by defining / providing the conceptual and technical priorities and thereby promoting informed decision making

Going by the premise, what is not measured does not get managed, it is important to identify the measurable objectives for the Architecture function itself, so that it is well managed and its contribution to the success of the organization is established. While measurement of Architectural activities is difficult, COBIT suggests a set of measurable outcomes and performance measures, some of which are the following:

Number of technology solutions that are not aligned with the business strategy - One of the objectives of the EA function should be to ensure that the technology solutions chosen or implemented are aligned to the business strategy a measure around this could be very useful to establish that the number of misaligned solutions are on the decline. There could be other measures derived around this and could be represented as a relative measure to the total solutions.

Percent of non-compliant technology projects and platforms planned - With the fast changing business environment, there will be times when the business will need to solutions technology projects that are not compliant with the standards and principles laid out by EA. EA has the responsibility to carefully review such needs and grant waivers. Such waivers should be for a shorter term and should be backed with a plan to normalize it. At times, this could call revision in the standards, policies or principles. A measure around this could be very useful that the EA is effective in dealing with non-compliant technology projects and platforms.

Decreased number of technology platforms to maintain - Standardization is one of the objectives of EA, which could contribute to cost reductions and reduce the technical complexity. Statistics and surveys show that enterprises without an active IT Governance / EA function have more multiple applications requiring different platforms for the same business requirement being used by different departments. With an effective EA function, these should be very less in number and should decline over a period. A measure around this is a very good indicator of EA being effective in this area.

Reduced application deployment effort and time-to-market - Supporting Business agility is yet another key objective of the EA function. Today’s businesses are operating in a highly dynamic industry environment and in order to stay competitive and to sustain its market position, need support from IT to have the new or changed capabilities with a reduced time-to-market. A delayed delivery from IT could mean an opportunity lost. A measure around this indicator would really be helpful in establishing how IT is supporting the business changes.

Increased interoperability between systems and applications - It is quite common that most enterprises have multiple applications for specific needs, but there is a need to have these applications share data and information amongst each other. With cloud computing gaining wider acceptance, most enterprises are looking at discrete cloud based solutions. With the benefits outweighing the concerns and constraints, and that the industry is working towards addressing these concerns, there will be increased focus on move to cloud. This will mean hosted applications from various providers would need to be interoperable and working with other in house applications. EA should ensure that the technology and solutions acquired or designed should support this important attribute i.e. interoperability. A measure around this parameter would be an important indicator of EA function’s effectiveness.

Percent of IT budget assigned to technology infrastructure and research - Yet another expectation from the EA function is that it should help businesses in leveraging emerging technology to its advantage. This will require the Architects to be continuously looking for newer technologies and its application areas, and recommend such technology or solutions for implementation so that the business will get the most out of IT to accomplish its mission. It is also important the extent of this activity should be in line with the identified and stated role of IT in the organization. While the percentage of IT budget used for research is an useful measure, there could be other useful measures derived from this, for instance, number of research solutions getting implemented as a percentage to total number of solutions implemented in a given period. Business satisfaction on timely identification and analysis of technology opportunities is another related measure which is indicative of the outcome of this research.

Number of months since the last technology infrastructure review - With the fast changing IT space, it is important to ensure that the technology infrastructure is of continued relevance to meeting the business objectives and if needed changes should be considered. A measure indicating that the EA function is performing review of the technology infrastructure periodically is a good indicator of its effectiveness. Measures derived around this review could be based on the outcome of the review will also be very useful.

There is no one size fits all in IT and as such the measures indicated above need to be tailored to suit the organization and the role of IT within the organization.

References:

COBIT - an IT Governance framework from ISACA.

Developing a successful governance strategy - A best practice guide for decision makers in IT from The National Computing Center, UK

---

PPM - Project Categorization

PPM is about ‘doing the right things right’ where things refer to work efforts, projects and programs, doing the right things refer to prioritizing and selecting projects and programs in line with the strategy & objectives of the organization and doing things right refers to execution of projects and programs in such a way the benefits are realized.

Portfolios, programs and projects are all formal expressions of resource assignment decisions. Accordingly, a systematic approach to collecting, selecting, planning and managing them is key to a high-quality Governance process. Projects, programs and portfolios share a common life cycle formed around four key stage gates, which are Create, Select, Plan and Manage. In the context of portfolio, an important and first task is to determine the investment types or categories with which the project or program are categorized. The purpose of this blog is to examine the need and methods of project categorization.

Purpose of Categorization

Broadly, the following are the purposes for which organizations find categorization useful.

Strategic alignment: Certain projects share common characteristics that will mean a common approach with respect to prioritization, project tracking and monitoring, strategic visibility, etc. Appropriate categorization of projects would offer better visibility in terms of strategy execution and benefits realization.

Capability specialization: Another reason, organizations would be interested in categorizing projects is to identify and group similar projects, so that they all share common tools, technology and terminologies, which will help better management of resources and communication across projects.

Promote project approach: Though this purpose is of minor nature, it helps organization to promote the project culture and differentiate operations from projects and also to use a common methodology to manage such projects

The following table presents a mind map of organizational purposes around categorization:

Primary Purpose	Sub Purpose	Benefits
Strategic Alignment	Selecting / prioritizing or projects / programs	Alignment commitments with capabilities
		Managing Risk / controlling exposure
		Allocating budget
		Balancing portfolio
		Identifying approval process
	Planning, Tracking adn Reporting of	Resource usage
		Performance, Results, Value
		Investments
		Comparability across projects, divisions, organizations
	Creating strategic visibility	Visibility across projects, divisions, organizations
Capability Specialization	Capability Alignment	Choosing Risk Mitigation Strategy
		Choosing Contract Type
		Choosing Project Organization Structure
		Choosing Methods and Tools
		Matching of Skill sets to Projects
		Allocating Project to Organizational unit
		Setting Price
		Enhancing Credibility with Clients
	Capability Development	Developing Methods and Tools
		Managing Knowledge
		Developing Human Resources
		Adapting to Market / Customer / Client
Promoting a Project Approach	Providing a Common Language	Facilitate better Communication
	Distinguishing Projects from Operations	To Better Manage the Work Efforts

Categorization Schemes

None of the standards or frameworks specify a particular scheme with which to categorize and it is left to the organizations to decide on the scheme that best suit their needs. It has been found that most of the organizations use a multi-dimensional composite attribute based categorization schemes.

Here again the following three broad approaches are in wide use:

Hierarchical scheme: In this scheme, projects are hierarchically grouped based on multiple attributes. For instance, at the top level, the projects may be categorized as small , medium and large, based on the estimated investments and then further categorized into the application areas like, Infrastructure, Enterprise Applications, Field Applications, etc. There could be further categorizations as well. Under this scheme, each project falls under one unique category under each level.

Parallel scheme: Unlike in the hierarchical scheme, in this case, projects are assigned several sets of attributes. For instance, the projects may be categorized by complexity, technology and strategic importance and a project may find a place in all three categories.

Composite scheme: In this scheme, the categories are determined based on the result of applying more than one attribute. For instance, the category project management complexity may be determined by combining multiple attributes like team size, number of units or modules to be delivered, development efforts, duration, etc. Similarly a category deployment complexity may be based on attributes like process impact, end user scope of impact, project profile, project motivation, etc.

Conclusion

There is no single scheme or approach that best suits an organization. It is for the people involved in the IT / Business Governance to carefully choose the categorization based on the organization’s Vision and Strategy and then create a process to consistently determine the appropriate category for a project so that the relevant strategic and tactical tools and methodologies can be applied to that project as well, which in turn will ensure realization of the intended benefits with a desired level of efficiency and effectiveness.

References:

Aligning Capability with Strategy: Categorizing to do the Right Projects and do them Right

Project Portfolio Management: Doing the Right Things Right

---

Top 4 Principles for IT Leaders to focus on

Experts predict that IT Leadership is taking a hit as the business is not happy with the value that IT delivers. The emergence of Cloud and SaaS based Applications have made the business leaders to think that they can get the needed IT support as services, though they are unaware of the issues or challenges with that idea. But this has certainly made the IT leaders to think and do a self-assessment in terms the focus area and the value delivery. Here are the four principles that may help IT leaders to continue delivering value to the business and thereby ensuring their very existence.


Embrace the Business Change

In today’s competitive world, Businesses need to revisit their vision, mission and strategies too often than they did in the past. This most of the times will call for change to the people, process and technology and depending on the priorities, such change may have to happen too soon. IT traditionally has been resisting changes, though with Agile and other approaches, Changes are welcome, but due to various other factors like the maintainability of the systems, cost of change etc, the IT is finding it a challenge to embrace such changes. This is why business leaders are trying to explore options to minimize their dependence on their own IT, so that they can move on with the desired changes quicker and reap the benefits of the change.

For IT leaders, embracing change is a challenge as most of them are still living with legacy systems which have very poor characteristics in terms of scalability and maintainability. The IT leaders should find ways to overcome these barriers and should be willing and ready to support business changes. The solutions include, revisiting their application design principles with a view to ensure that all their current and future custom applications are Service Oriented and are highly scalable, maintainable and performing. For other legacy systems, explore options to service enable them using appropriate tools and technologies, without changing systems themselves.


Focus on Value Delivery

Though traditionally IT has been a cost centre, most IT leaders have shown interest in treating IT as a profit centre. Most IT investments, though are evaluated in terms of the return (value) that this investment brings back, this is not monitored throughout its execution. Ideally, the focus on value should not be lost during the execution phase. This is true as the discoveries or problems encountered as the project execution progress may have a significant impact on the perceived value and in such cases, it would be wiser to take call to fail the project and call off further investment without waiting for the end result.

When something is offered for free, everyone will want it whether irrespective of there being a real use for it. Similarly, applying the 80/20 rule, 80% of the business functions are likely consume only 20% of the IT services. There need to be a method or process to keep accounting the service offerings and identify the 20% of services and prioritize the support for these services in terms of taking up changes around these and delivering them faster than expected by the business.

Bringing in a culture (at the least within the IT function) wherein the need for focus on value delivery is well understood and demonstrated by all would certainly help achieve greater benefits overall. Every member should know and be aware of the expected business value of every project or sub projects and that they are associated with and should take pride in ensuring that their actions in fact result in the business enjoying the perceived value.

IT Leaders should devise suitable process or systems which will help measure everything and use it in turn to calculate and publish the metrics or statistics around the business value delivered by different projects or investments. IT Governance frameworks like COBIT can help achieving this.


Communicate & Collaborate

IT leaders normally express their point of view technically, which the business users or leaders may not get it right and eventually the value proposition might not be understood well. This is where IT leaders should start putting across their proposals or point of views in a way that make sense to the business leaders. While the converse is also true that while Business leaders talk about business changes, IT leaders find it difficult to understand, which IT leaders should overcome. IT is important that the IT Leaders and the most part for their team should be willing to acquire the required business skills and should demonstrate the same in their communication and deliveries.

Similarly, it is important for the IT leaders to collaborate with the business proposals and get involved right from the initial stages, so that they are able to get to know the business requirements and priorities better and at the same time present them back with the various risks and caveats that related tools and technology that enables this change may bring in for them to manage.


Talent Development

With the technology landscape changing rapidly, and the business leaders are looking for such enabling technologies to gain competitive advantage or to improve the efficiencies at various levels, the IT team has a pressing need to cope up with such needs. This is where, IT leaders should now look for people with multiple technical and business skills and with the willingness and ability to learn newer technology and business skills faster. This should be best achieved through mentoring and not by force.

IT leaders together with the HR leaders should also provide the employees an environment, which is conducive to develop the abilities of the employees. The organization culture should also envision the need for continuous learning and devise a system to measure and monitor the efforts spent in learning. For instance, depending on the role, the employees may be asked to log certain number of learning hours in a year on specified technical and business areas.

The IT leaders should also be continuously learning and stay on top of the technology trends, so that they can identify the right technology and tools that can improve the service capabilities of the business functions and in turn could give competitive advantage.



Right strategies around these four areas would certainly help IT leaders stay focussed in the business benefits and in turn demonstrate measurable value on IT investments.

Cloud Computing - Governance Challenges

I recently happened to read a Technical Note published in October 2006 by Software Engineering Institute titled as ‘System-of-Systems Governance: New Patterns of Thought’. The technical note was primarily aimed at organizations like Department of Defence, where in multiple organizations and systems need to collaborate to form part of DoD as the bigger enterprise. The Note discusses about some of the key areas where the traditional Governance would need a review and revision to handle the very nature of the System-of-Systems.

CIOs are in favour of embracing cloud and as such would have contracted for multiple software systems (SaaS) for different needs, for instance Salesforce for its CRM needs, ServiceNow for its IT Service Management, Windows Azure for custom application development, NetSuite for its ERP needs and so on. Similarly the IT organization would have contracted with different cloud service providers for its Infrastructure (IaaS), Storage and Platform (PaaS) needs. The XaaS list is growing as we are now seeing offerings from vendors for Database as a Service, Security as a Service, Identity as a Service, etc. With all this multiple contracted system components, the IT organization certainly has challenges in implementing governance practices, as there are diverse systems components forming part of the larger system.

In today’s world, with increasing cloud adoption and outsourcing activities, we could see business organizations are in almost in the same state as it is described of DoD, i.e. System-of-Systems and the key governance challenges very much hold good to be addressed. The following are the five amongst the six areas that need to be looked into to realign the governance practice within an enterprise:

Collaboration and Authority

With systems and components owned by various organizations being in use, even if owners of constituent systems are unusually committed to the system of systems, a single authority is likely to be ineffective. And if authority is essential to the enforcement of IT policy, then without sufficient or inadequate authority independent vendor organizations can always be expected to have reluctance in adopting shared policies. Collaboration amongst the constituent system owners is required at least in problem solving, participating in decision making process, coming up with provisional solutions to meet an emergency need. While the cloud computing is still maturing, there is a need for standards to emerge which should facilitate the necessary collaboration both technically and in terms of policy federation.

Motivation and Accountability

There should be motivation for anyone to adhere to or adapt to a shared policy. Enforcing such shared standards or policies across independent vendors would not work as effectively. The Technical Note refers to Zadek’s five stages of learning that organizations go through to achieve the benefit of voluntary collaboration. These are:

Clic on the image to view a better image

The table above not only shows what motivates organizations at different stages but also reveals what they may need to learn. For example, a defensive organization that claims common system-of-systems practices are irrelevant may need to be educated about threats to its reputation due to its lack of voluntary compliance. At all stages, we need policies to give individuals and organizations the incentive to do the right thing.

Multiple Models

A simple example to highlight how this area is significant could be the security implementation within the component systems. Each component and system vendor may have different security models implemented within the individual systems and that complicates the governance of the overall organization challenging. This calls for the need for a dynamic governance model, which can map and interact between different models of the individual components. While security is just one example there are other areas where the components are designed and modelled differently. While framing the Governance policies to suit all such systems certainly is not the good approach, the governance framework should provide for variables based on type of systems or type of service or a similar category.

Expectation of Evolution

This can be easily related to change and release management of independent vendor systems and the change of the common infrastructure of the enterprise itself. If governance cannot eliminate the independent evolution of components within the system of systems, it should aim to reduce the harmful effects of uncontrolled evolution by the component systems. Thus, policies must be created and enforced to provide rules and guidance for components as they change.

At a minimum, governance for evolution should include rules and guidelines for

• informing other components systems (when known) 12 of the changes in the interfaces to and functionality of one system
• coordinating schedules with other component systems so that those that have to change can do so together (when backward compatibility of interfaces cannot be maintained)
• maintaining multiple versions of the system when schedules cannot be coordinated
• developing each system to insulate it from changes in other component systems
• minimizing the perturbations to interfaces when changing a system

Highly Fluid Processes

Agility is the order of the day within every function of the enterprise. Being agile and responding to changes quickly gives the competitive edge to the enterprises and that is equally applicable for the Governance Framework as well.

Planning for rapid changes in system-of-systems governance is needed. For example, governance strategies may provide a mechanism for adapting to rapid policy change, such as a way to relax security policies to achieve some urgent goal and then tighten them up again. Governance policies should be framed in such a way that those around the systems or components which is likely to see problems or changes too quickly should have flexible policies and whereas as we move away from such systems, it should be relatively stable. For example, a neighbourhood of closely related systems might be the first to notice a problem with a current component or process and will need to respond quickly. At the extreme, where neighbourhoods of related systems are themselves fluid, some details of system-of-systems governance policies might be negotiated.

Summary

As with the technical note, I have not attempted to suggest solution for the governance challenges listed above. Organizations like ISACA have been researching on Governance issues and its widely adopted COBIT framework would have solutions for these problems, which we will explore in my future blog posts.

References:
SEI's Technical Note - System-of-Systems Governance

The pressure points of Cloud Adoption

The values and benefits of cloud adoption is increasingly clear and well known. Not to be carried away with these values and benefits, it is important to identify and be aware of the pressure points that the Cloud Adoption brings in as called out by ISACA in its white paper titled as ‘Guiding Principles for Cloud Computing Adoption and Use. Essentially the differences in technology itself and its use impacts the way IT is governed and managed and the management’s reaction to these impacts brings on the pressure points as well, which need to be managed.

Differences such as change in cost allocation from capital to operational may have consequences that may not apparent at the beginning. For instance, contracting for a cloud based software would be an operational spend and may have a lower cost of entry and thus, such decisions may fall outside the review and approval process. While in most cases, the pressure points are to be managed as risks, these are not necessarily risks.

Speed and Agility

The time-to-market is a driver for cloud adoption as solutions to meet market needs would be available more quicker at lesser cost though there could be gaps in meeting the exact requirements. This agile exploitation in a reduced time frame puts greater pressure on enterprise, in which culture, process, and human factors related to technology have been developed to support longer development cycles and long term technology use. This pressure when not handled appropriately could result in increased risk level in the following areas:

• An unbalanced prioritisation of value over trust in technology solution choices
• Missed opportunities when other alternatives are not considered
• Recovery mishaps because fallback positions are not fully exploited
• Missing functionality if full requirements are not identified
• Increased long-term costs due to reliance on multiple short-lived solutions
• Reduced performance when enterprises are hesitant to introduce new solutions because of existing technology investments

Changing Boundaries

The reliance on cloud providers calls for change in the roles and responsibilities within the enterprise and transfer certain responsibilities to outside parties. Contracts and SLAs with service providers attempt to assign accountabilities, but governance dictates that the enterprises themselves, their board and management remain accountable. With this, the locus of decision making changes from governance functions to business line leaders. This change in the organizational boundaries can put greater pressure on enterprises. The risk outcomes out of this pressure point could be:

• Role confusion when accountabilities and responsibilities are not clearly defined
• Diminished effectiveness when decisions are made without engaging in a wider consideration of trust and value before cloud acquisition
• Failure to satisfy constituent and end-user expectations for protection and privacy
• Project delay and increased costs due to the need for personnel with governance responsibilities to revisit cloud plans
• Unclear specifications of provider responsibilities and accountabilities in SLAs
• Incomplete information being provided to board members and senior management

New Technologies and Technology Expectations

Cloud follows a sequence of disruptions in how technology is viewed, integrated into organizational strategy and managed and in how IT risks are identified and managed. Areas of high pressure can result when strategy and enterprise architecture do not consider the unique qualities of cloud computing and when enterprise processes and procedures do not easily adapt to changes made possible by cloud computing. The following risks could be the outcome of this pressure point:

• Missed opportunities to extract value from the integration of cloud and internal systems
• Increased vulnerability from incompatibilities and inconsistencies between cloud and internal systems
• Less than expected results when human factors are not considered in the design and integration of cloud services and infrastructures
• Levels of organizational performance that do not meet expectations because cloud solutions do not fully support organizational processes
• Levels of technical performance that do not meet expectations because processes do not take full advantage of cloud capabilities

Level Playing Field

Cloud computing removes the advantage that large enterprises have traditionally had in terms of availability of technology specialists and technical sophistication. Smaller enterprises now have the ability to leverage the cloud services and use technology sophistication that large enterprise used to enjoy. This brings the small and medium enterprises on an equal position with much larger enterprises. This level playing field can have an impact on the strategy and its implementation. Ignoring this impact can result in increase of risk levels in the following areas:

• New entrants claiming a segment of traditional market dominance
• Strategies that do not address competitor capabilities
• Less-than-expected benefits received from technology-dependent solutions

Utility Services and Service Supply Chains

With cloud computing, where computing is viewed as a utility, focus is shifting to the value and benefits obtained from such utilities. Agile enterprises benefits from solutions that can be used as needed and discarded when they no longer provide value. This view of computing as a utility and the delivery of solutions supply chain of information systems solutions puts greater pressure on enterprises that contain a culture that is not accepting of utility solutions, a structure that does not facilitate cooperative planning and processes that cannot take advantage of computing solutions provided as supply chain of utilities. Ignoring this could result in the following risk outcomes:

• Over-investment of resources in planning and building internally developed information system solutions
• Less-than-optimal results when value-producing cloud utilities are missing from the total solution
• Duplication of effort when specialist services available through cloud providers are not integrated as part of system management
• Less-than-expected results when utility components are not integrated into and managed as an information system capability supply chain

In the white paper, ISACA suggests that enterprises follow a six guiding principles that can help illuminate the path for cloud adoption. Click here to download the complete white paper which is available for registered (free registration) users.

Key risk areas that can impact the project success

Till recently and to some extent, even now, some of us don’t want our insurance advisor talk about our own risk of life. It has been the belief for some not to think or talk about the risk of losing life. However, things are changing and most of us today are managing personal risks well by atleast transferring the risk to the insurer for financial protection. Risk management is not just financial protection and there is more to it, even though finance makes the core part in most cases. The same way, if we look at managing software projects, the project manager and sponsors had to deal with so many issues every now and then, before it was felt that preventing such issues coming along the way is better than dealing with such issues, which is what is risk management.

The risk managers or risk experts always think of a what if scenario for every action / decision so that all possible risks are identified early on and this in the past was thought to be creating ‘negative vibes’ and did not receive much support from the project sponsors. Because, when much of the risks are identified upfront, it might be so that the project may have to be shelved at the start itself. Here again, things have changed and most CxOs are accepting ‘failing fast’ a better option than failing at the end. Failing at start is an even better option. Refer my own blog on ‘failing at start’.

Given that most of the project sponsors and project managers have realized that risk management is better than its only alternative crisis management and are believing that risk management is a key area of project management, let us explore the key risk areas in a broader context that need a close watch which if not could impact the success of an end to end software project.

User Expectations

Even though a well written functional specifications exist, and the development team developing to that requirement, there is a potential risk of end users when they look at the final product go back and say that “this is not working in a way we want’, and pushing back the product for rework. This is mainly due to the fact that everything around the business is changing with time. The more time the development team take in involving the end users, the chances are very much likely that the expectation would have changed. Agile is the solution to address this risk area, where by the end users are participating in the development and small chunks of the product are delivered every now and then for user feedback.

There are more to it, most projects do not have the non functional requirements documented and much of the user expectations go around such software capabilities, for instance application performance is a key non functional requirement, which the development team is expected to take care of as part of. While the solution for this lies with the solution architect, the project manager and the stakeholders should not lose sight of this important area and should be managing the user expectations all through the project execution.

If one can identify or spot the potential risks around the user expectation and manage it well, the chances of the project successfully reaching the milestone is very high.

Technology Shocks

This is a broader risk area and could be broken down into many sub areas. Many projects hit a road block when it get closer to production deployment, by when the infrastructure team may find heavy investment in terms of hardware and software tools required to support the product in production. Some projects even faces issues in the early stages as well, as the development team may find some tools or technology not suitable for the given solution.

A well done pre-project risk assessment can help address this risk as the architects involves in such assessments can anticipate and call out such road blocks, which might help the project sponsors to take a call. Development teams in most cases would want to jump on to the project and start building everything themselves without considering re-usable off the shelf components being available for most capabilities. This tendency can add to the schedule risk, as the project may take longer due to technical issues that the team may face.

Managing risks in this area early on is very important as certain choices might be very difficult to reverse in the middle of the project. It could also be a case where implementing certain requirements with a given technology platform or tools could be much more complex than with certain other tools. Much of this responsibility lies with the Architects, who should do a good job to take the project pass through this risk area.

Skill gaps

While this item is to some extent related to technology shock, there is more to skill than the technology itself and that made me to call this out as a separate risk area itself. Soft skills play a key role in taking the project on the success path. Staff attrition is inevitable in software projects and as such managing the dependency on people is very important. The resources holding key roles should have the right attitude of hand holding the teams, willing to share the knowledge, quick and effective in on-boarding new members to the team.

Such skills of key resources holding the lead role even influence staff leaving the team or even the organization and it could be some of the best resources of the project team exiting for such reasons. The Project Sponsors should play an important role here in getting to know of such risk items and manage them well so as to keep the morale of the team high and get the best of the team.

Every member of the project should contribute towards the success of the project, keeping in mind the project goals and objectives. It is not uncommon that some key members of the project make certain decisions in such a way that is beneficial to him or them and in turn putting the success of the project at risk. This is a sort of political behaviour by some members within the project. Here again, the sponsors should involve more into the project and look for such risks spotted early on, so that control measures can be put in place by changing the team composition or by imparting necessary training or counselling to the needy members.

This third risk, when identified and managed well will ensure the team members collaborate and communicate well and deliver their best which eventually will contribute towards project success.

Lack of Risk awareness

Finally, lack of risk awareness by the project stakeholders is the biggest risk. This calls for a proper risk strategy and objectives at the organization level and at every project level and letting every member of the project to actively participate in risk identification and management.

While most project managers do mandate risk management as part of the project charter and do maintain a risk register, they fail to apply the risk management principles consistently, which eventually lead to incorrect risk prioritization. Not to be stressed, the controls and tasks identified to reduce the risk level also need to be monitored on par with other project tasks for timely actions. It is also a common mistake that the project managers do by missing out to estimate the efforts for risk management and not making it part of the project schedule.

Another important aspect of risk management, which is normally ignored is the communication and continuous monitoring. Risks need continuous monitoring and need different levels of communication or escalation depending on the risk level. Most projects have a stale risk register, where the risks are just identified and no monitoring or follow ups being done on them. Use of an appropriate risk management tool is recommended as it will ensure the visibility of the risks to all concerned with automatic alerts and escalations and also will facilitate consolidation of risks across multiple projects, there by facilitating managing risks at enterprise level.

Pre-project Reviews help projects fail at start

A new project was approved and a 15 member team sit round the table in the project kick off meeting with excitement and enthusiasm. Business Analysts have put together the stories which Developers have started developing. There were periodical project status reviews and there were issues and risks discussed in these meetings and the project manager did well in managing the issues and risks. There comes a message from stakeholders that all work on the project be stopped with immediate effect.

That may be sounding familiar to every IT familiar as study says that 37% of the IT projects are at the risk of failing. Another study finds that 31% of the projects are cancelled before even hitting the finish line.  It really hurts the project team members when a project is cancelled or shelved. But there could be reasons for doing so and such decisions are taken when continuing with the project will only increase the loss and would not bring in value for the sponsors. This is where ‘fail fast’ will help as some times pulling the project down even earlier would save a lot of efforts and money for the sponsors.

Let us see what can be done even before starting any work on a project, so that the potential failure is spotted in the pre-project stage itself so that the project is not allowed to start in the first place. When the need for a project is felt, the executive management (sometimes called Project Review Board) takes a look at it and reviews it and if it sees merit in it, gives a go for the project. In some cases, by the time the Project Review Board (PRB) sees the project proposal, considerable efforts would have already incurred in the form of requirement gathering and analysis. The review by the PRB members, when done well will bring out the ability to measure the risk exposure and the RoI (Return on Investment) of the project, which in turn influences the further decision. However, it is important here that the PRB members shall be presented with adequate information that helps taking the right decision. A well drafted checklist or template that captures all the required information would help not to miss out the details and will help reduce the projects failing down the road.

The project proposal template shall at a minimum capture the following details, so that an informed decision is taken by the PRB.

Motivation:

The problem the project is expected to solve or a business opportunity that the project will help the business to capitalize should be stated well, so that the PRB members are able to appreciate the motivation behind the project need. It would be appropriate to quantify the value / benefit the solution would bring when implemented as intended. Some projects may bring immediate benefits, whereas some may bring benefits in the longer term, in which case, the same shall be called out explicitly. Similarly some projects may bring in monetary benefits, while others may bring in intangible value / benefits.

Estimated investment:

It may not make sense if the investment to be made for the project is significantly higher, which may leave the value or benefit negligible. Most projects get hit on account of cost overrun. The estimate should be close to being accurate and use of a template will make sure that all cost elements are considered. In some cases, a better estimation can be made only after gathering requirements with sufficient details. It would be wise that in such cases, the PRB may take a call to sponsor the initial efforts alone and let the proposal be placed again for review with more accurate estimation.

Constraints:

All projects will be constrained with various ifs and buts. Each possible constraint should be identified and called out in the proposal document. Each constraint will have one more associated risk items for which a contingency plan and mitigation plan has to be put in place. Risk Management practice has evolved in recent times and there are methods and techniques with which the risks can be quantified (a factor of probability and impact) and the overall risk exposure of the proposed project can be measured. This will help the reviewers to take an informed decision whether this much risk is worth to be taken for the value this project might give back.

Solution longevity and re-usability:

It would help if the expected life of the solution is determined. Some of the solutions may have shorter life, but may offer the re-usability with minor changes / enhancements. This will have to be determined considering the longevity of the tools and technology that forms part of the solution. Considerable number projects get cancelled as the sponsors gets to know that the useful life of the solution is going to be short and that the project may not be completed on time leading to further reduction in the longevity.

The above are some of the key factors that influence the decision on the project. There are many other factors which depending on the nature and size of the project may have significant influence on the decision making. For instance, security and compliance requirements could be a significant risk, which the PRB needs to know of while taking the go decisions on projects. Other factors that may find a place in the Proposal document include, deployment infrastructure, post production maintenance aspects, choice of technology, resource availability, etc.

On top of everything, the team that prepares the project proposal document should have the expertise in the business domain, technology used, estimation and related skill areas. Typically this will require a team of architects of appropriate specialization to accomplish this.

References:

http://www.zdnet.com/blog/projectfailures/cio-analysis-why-37-percent-of-projects-fail/12565

http://www.it-cortex.com/Stat_Failure_Cause.htm

http://www.articlesbase.com/training-articles/project-failure-what-are-the-reasons-for-and-statistics-on-it-871395.html

GRC for IT Architects

Governance Risk and Compliance (GRC) as most of you might know, is more than a catchy acronym used by IT and security professionals and in fact it is an approach or framework that an organization adopts to ensure proper management and control. 

The broader term Governance calls for a better way of managing the business, which includes protection of the assets of the organization (includes information as an asset), sustainability of the organization irrespective of the business or economic climate. Risks are the unforeseen events or forces which could potentially result in severe impact on the overall performance of the organization.  Better Governance cannot be achieved without a good risk management program in place. The risk appetite of an organization should be known to the stakeholders who should manage or control the risks, so that the risk exposure is well within the risk appetite. The term Compliance denotes the organization’s approach to being compliant with various legislative requirements of different countries in which it operates and also to comply with social commitments.

GRC exists at different levels, for instance Governance could exist at the corporate level, project level or at sub organization level. While the goals of the GRC at various levels will be the same, the means or techniques used to achieve it vary. 

As one could observe these three terms have inter-relations amongst each other and it’s for that reason, there is a need to have a 360 degree view of all these three together. GRC aligns various components of the enterprise (processes, employees, systems and partners) to be more efficient and more manageable leading to better business performance.

An organization is primarily comprised of People, Processes and Technology. The technology domain in turn is made up of Data, Applications and Infrastructure. The Corporate GRC goals can be met when these components are aligned to meet the respective goals.

Much of the risks that today’s organization is battling with are around Data and Applications used within and outside the organization. The IT Architects in turn play important role in designing the solutions involving data, applications and the infrastructure. Thus it is important for the IT Architect that the solution design process is aligned to the GRC framework of the organization.

Information Systems Audit and Control Association has recently released COBIT 5, which helps organizations to get more value from both information and technology investments. By approaching Governance, COBIT 5 helps maximize the trust in and value from organization’s information and technology. Let us go over some of the questions the stake holders would raise on the governance and management context of enterprise IT and see how it will be relevant for IT Architects.

How do I get value from use of IT? Are end users satisfied with the quality of IT?

IT investments are about enabling business changes and are expected to bring enormous value to the business. But 2 out of 10 enterprise IT projects are outright failures. Keeping a focus on the value delivery from proposal stage till delivery of the solution is likely to improve the chances of success. The Architects should establish the business value that the solution could bring, so that the stakeholders can make an informed decision whether to go ahead with the investment or not.

The perceived value out of IT investments is also dependent on user satisfaction on the service delivery using the solution. The usability should not be ignored for any reason by the Architects and to achieve this Architect should collaborate with target end users on a continuous basis to solicit and elicit feedback.

How do I manage performance of IT?

As businesses heavily depend on IT, the performance of IT to the satisfaction of business is important. Among various other reasons, poor or sub optimal solution design is a major cause for IT’s non performance. Here again, IT Architects have an opportunity to factor the best design practices and ability to generate appropriate metrics so that each of the IT services can be measured and monitored in terms of its performance.

How do I best exploit new technology for new strategic opportunities?

Information Technology is advancing in a faster pace, and the trends are shifting too frequently. Newer tools and technology frameworks that come into the market make enabling business changes more and more easier. This at the same time calls for the people’s abilities in mastering related skills. The Architects has to do a balancing act in not missing the opportunities that the newer technology and tools have to offer and at the same time should not risk the business by taking on such changes so early when skills to manage it is hard to get. Many a times, exploiting new technology ahead of the completion can spur business growth.

How dependent am I on external providers? How well are IT outsourcing agreements being managed? How do I obtain assurance over external providers?

Organizations are embracing cloud and started looking at SaaS applications as these offer a higher degree of flexibility in terms of investments and in terms of capabilities. This is happening though there exist quite many security and other compliance concerns that the industry is still trying to address. This resulting in more external vendors being engaged, calls for a well drafted SLA, which should be in line with the security and regulatory compliance needs of the organization. A careful evaluation of the product and the vendor is essential as it does not absolve the organization from this compliance needs.

What are the control requirements for information?

Information and data as assets are gaining significance and in the next few years, the ability to control and manage large volumes of data from discrete sources in an efficient and effective manner will be looked forward by almost all organizations. At the same time, data breaches are also on the rise and the information security practice is also drawing considerable attention from the CIOs. It is time that the CIOs or CSOs put in place an Information Governance program, identifying and classifying sensitive data and information and defining the control requirements around the same. This will require the all the applications be designed appropriately to have these control requirements implemented.

Did I address all IT related risk?

Risk is one of the important area to be managed well to minimize uncertainty and the associated impact on the business. Risk Management has to be practiced at every level including IT Architecture. IT Architects start risk management right from proposal stage to delivery and even after that. Lack of Risk Management skill amongst the Architects could itself be a risk.

Am I running an efficient and resilient IT operation?

With high dependence on IT, today’s enterprise needs an efficient, effective, secure and resilient IT infrastructure for its survival and success. This requires the sub systems of IT to be highly performing and at the same time architected in such a way to be flexible enough to accommodate changes to it. The Architects should always be willing to embrace change and make sure that the solutions that they design is receptive such changes.

How do I control the cost of IT? How do I use IT resources in the most effective and efficient manner? What are the most effective and efficient sourcing options?

The Architects who design IT solutions are not usually constrained by a budget, and so why in most cases the solutions designed are not necessarily a cost efficient one. Ideally, the Architecture team should consider better budgeting and estimation techniques and should be able to quantify the capital and operational costs, which allows the stakeholders to take informed decisions.

Do I have enough people for IT? How do I develop and maintain their skills, and how do I manage their performance?

Choosing the right tools and technology should also mean that availability of people in to manage and support it. Architects sometimes get carried away by the features and abilities of such tools and sometimes carried away or influenced by vendors and eventually end up in a situation where incurring huge cost in finding skilled people and retaining them. Architects should seriously consider the talents available in house and the availability of such skills in the market on demand, while making such choices.

How do I get assurance over IT?

Quite often, the IT is pulled in to diagnose the problem of an application coming down crashing. Teams like Developers, Architects, Network engineers, Hardware engineers, etc come together to trouble shoot the problem and come up with a corrective and preventive action. Every such instance throws a new root cause and the teams keep on learning out of such outages. But what the end user community wants is a stable and reliable system, which the business can depend on. While it is hard to rule out outages, there should be processes in place, which helps reduce the down times. The systems should be designed to being able to log information necessary for trouble shooting, raise alerts upon encountering exceptional conditions, factor redundancy in hardware and software components. Periodic audits and reviews should be carried out to ensure that the recovery measures put in place are working.

Is the information I am processing well secured?

With cyber security crimes on the rise, organizations are investing heavily on securing the data and information assets that are stored within and outside the organization. IT Security should be one of the key non-functional requirements that the Architects should consider while designing solutions. The significance of Security needs could vary based on the organization’s nature of business and the information being processed or stored. Many countries have pronounced legislations on security requirements for specific industries and specific class of data, which should be complied without exception. Here again, period audits and reviews would help assure about the IT security level to the stakeholders.

How do I improve business agility through a more flexible IT environment?

Agility is key to quickly turnaround business changes as solutions. Flexible IT enables the organizations to quickly capitalize on the new opportunities, to innovate and to get ahead of the competition. This saves time and increases efficiencies. Some of the key evaluation or design criteria to make this happen are:  shared / outsourced infrastructure, ability to scale up and scale out, reduced complexity, continuous data and application availability, built-in efficiency within every component, etc.

The above is not an exhaustive list to be taken care by the Architects. Most of the above would be addressed if one follows the best design practices considering all of the undocumented abilities (scalability, availability, maintainability, usability, etc.) required out of the solutions and applying the right design patterns.

Reference: COBIT 5 published by ISACA, COBIT 5 and GRC

Emerging Cloud Trends – Impact on IT

A recent Gartner Report identified five Cloud computing trends which could affect the cloud strategy through 2015. While Cloud Computing has a significant potential impact on every aspect of IT, the uncertainty, confusions and misunderstandings continue to exist and the five sub trends would be accelerating and need to be factored into the planning process. This means that the CIOs would be inclined to revise the cloud strategies to align with these trends. This will also mean that the enterprises would need IT workers with skills that could help in making this strategic shift successful. Here are the five sub trends and the skills that these trends would demand.

Formal Decision Frameworks facilitate Cloud Investment Optimization

The benefits of cloud include the shift from CAPEX to OPEX models, reduced spending, greater agility and reduced complexity. These benefits do not come just like that and they come with some challenges in the form of security, lack of transparency, performance & availability concerns, vendor lock-in, licensing constraints and integration needs etc. It is important that these benefits and concerns are carefully mapped against the needs of the enterprise and an appropriate decision is made and necessary monitoring and management processes are put in place. Each of these benefits needs to be quantified considering the organization’s current and future priorities and constraints. For instance, a financial services firm may find the greater agility as a challenge as well (as against a benefit), because, greater agility could mean more frequent changes, which would have an impact on the reliability and stability of the applications. Realizing such impact in mid-course could result in rolling-back from cloud adoption and the resulting impact is obvious.

Over the next few years, organizations would be putting in appropriate decision frameworks, more specifically for the cloud adoption so that the benefits and risks are known upfront and decisions are taken appropriately. The skills that this trend may demand include Risk Management, IT Security, IT Governance, Estimation and Metrics.

Hybrid Cloud Computing as an Imperative

As there are enough reasons for enterprises not moving all their IT on to public cloud, Gartner sees a unified cloud model, where a cloud of clouds is a possibility, in which a single cloud may comprise of multiple cloud platforms part of which could be it internal. As everyone know, the key challenge with hybrid cloud computing is the integration of application and data between on-premise and cloud applications.

This calls for existing internal applications being enhanced to support integration with external cloud applications and at the same time the cloud applications should expose APIs for consumption by other cloud applications and / or the organization’s internal applications. Applications on public cloud need to adhere to industry standards and best practices, so as to support varying integration needs of its customers. The skills that an IT professional would start seriously looking at to get on with this trend are EAI (Enterprise Application Integration), SOA (Service Oriented Architecture), ETL (Extract Transform and Load) and EII (Enterprise Information Integration).

Cloud Brokerage will facilitate Cloud Consumption

As cloud adoption proliferates, so does the need for consumption of assistance. Gartner believes that Cloud Service Brokers (CSB) are one of the most necessary and attainable opportunities for service providers, service distributors and internal IT organizations. The CSB model provides an architectural, business and IT operations model for enabling, delivering and managing different cloud services within a federated and consistent provisioning, billing, security administration and support framework. This will help the unification of the cloud services delivery and management. Gartner has designated Jamcracker as a “Cool Vendor in Cloud Service Brokerages”.

This trend will call for the IT professionals to have a great deal of knowledge on SOA in addition to various standards, practices and tools on service provisioning, delivery monitoring, billing and management.

Cloud-Centric Design becomes a necessity

Migrating existing workloads with highly variable resource needs to cloud platforms is among the immediate opportunities that many organizations are looking at utilizing. But this will not make the cloud adoption complete, as it will result in using various work-around approaches to make it work with existing applications, by-passing standards and best practices. This might work in the near term and but may not scale and yield the real benefits in the longer term. Organizations should start looking at development of cloud-optimized applications that exploit the potential of the cloud. Even internal applications should be designed with cloud-centric model, so that it can exploit the private cloud platform and would make the integration with public cloud applications easier over hybrid cloud computing platforms.

This trend will expect the application and solution architects to start acquiring necessary cloud skills, so that the solution that they architect is cloud-centric and will have identifiable service end points for use with various other internal and external applications and also factor in the support for Cloud Service Brokerages. The design patterns, standards and practices around cloud-centric design is evolving and it is important for the IT workers to keep a watch in this area.

Cloud Computing influences future Data Center and Operational Models

In public cloud computing, the providers have implemented such a model so that the ability of provisioning, delivering and managing the services is optimized and automated to a great deal. This also ensures optimal utilization of the underlying hardware and also minimizing the energy and other operational costs. Enterprises are attempting to implement the similar models within their data centers and have private clouds setup for the consumption of their own internal consumers. This trend is increasing and Gartner predicts that in the next few years any data center (small or big, internal or external) implementation would follow the cloud model.

This trend will expect the Infrastructure Architects to be cloud aware and be familiar with the underlying tools and technologies, which form part of the cloud service provisioning, delivery and management.

Reference: Gartner report "Five Cloud Computing Trends That Will Affect Your Cloud Strategy Through 2015." The report is available on Gartner's website at http://www.gartner.com/resId=1920517.

SaaS Security and Compliance Concerns

Security is one of the major concerns which hold enterprises from embracing the cloud. But some think that this is manageable and as such have started adopting cloud based SaaS applications. Cloud based Enterprise solutions like Sales Force, Service Now, NetSuite are gaining ground. Let us attempt to list down some of the key areas, where the security and compliance needs are different from the on-premise applications.

Data Security 

Unlike on-premise applications, in case of SaaS applications, the underlying data is located outside the organization’s physical / logical boundaries. If the SaaS Provider in turn has hosted the application with a Cloud Platform or Infrastructure provider, then it is true for the Saas Provider too. This very fact that the data is located outside the enterprise could be a serious security concern for some enterprise, depending on the sensitivity of the data and the laws governing them.

Mature SaaS applications do expose Service Interfaces to facilitate data integration with other on-premise applications of the enterprise. Which means these Interfaces also need to be equally secured as these can be exploited to steal or manipulate data.

This means that the data as stored elsewhere should be secured by well established practices and methods like encryption, access control, etc. In addition, all the interfaces that expose data should also be secured using appropriate access control, authorization and logging techniques. The SaaS provider shall also make the data access logs available to the enterprise for review and audit.

Another important area to be concerned about is upon the service termination, how the provider ensures the proper return of the complete data and also make sure the destruction of copies maintained as the services may require.

When the SaaS provider assures adequate back-up and recovery tools and processes, it should also be ensured that the location of the back-up data is physically and logically secure enough and the data is stored with an acceptable form of encryption. Again, access to such locations should also be controlled, so that the SaaS consumers could access only their very own back up data and not that of others.

Data Segregation 

One of the key characteristics of SaaS application is multi tenancy, where an application instance is shared with multiple customers. That means, the customers’ data as handled by the application needs an appropriate physical or logical segregation, so that users of a customer access only their own data. On the consuming enterprise front, this could be a big concern as lack of adequate control could result in data being accessed by other consumers of the application, who could be competitors.

In this context, it is essential to know how the application and data stores are architected and what controls are in place to ensure isolation of customer’s data to its own users only. This is a larger issue and a lapse in one of the following areas could result in a compromise:

• A design or architectural flaw in the user authentication and / or authorization 
• A design or architectural flaw in the customer data separation 
• A defect in the user authentication routine 
• Regression issue caused by a design or application change 

Development Model 

 As we understand, how a flaw or change in the application could compromise the data security, the SaaS provider should also assure the consumers that their application design development model is developed to address the SaaS Security concerns. This means that the SaaS provider should have the following practices as part of their application design and development model.

• The developers should be security aware and the design and code that they produce should be of high standards. The development team should be well trained in remediating security threats as they are detected. 
• The development lifecycle should provide for security reviews and security testing at the end of every phase / sprint 
• As the application instance is shared by multiple customers, there could be need for customer specific patches and far more quicker releases of smaller changes. This may require agile development methods to be adopted. 
• The engineering process should include a configuration management process as the shorter release cycles and customer specific patches would require better source code control and more specifically in code branching and merging. 

Infrastructure Security 

Like in-house production environments, the environments where the SaaS application is hosted should be well secured. The SaaS provider should establish this fact by exposing the process and practices followed for the purpose by adhering to the popular security frameworks and standards. This need is the same as like in case of on-premise or cloud hosted enterprise’s own applications.

Regulatory Compliance 

There are a number of legislations in various countries, which stipulates for compliance to certain processes and practices when it comes to data. For instance in US we have HIPAA, SOX, etc. The SaaS model complicates this further as the enterprise may be operating out of a location in a country and the SaaS provider may be operating out of a different country and the data could be located in yet another country or even countries.

Again, in the SaaS provider perspective, customers from all over the world may subscribe for the application and in which case, the provider should establish necessary compliance practice to meet all such legal requirements. Some countries have legal requirements to retain data for certain minimum period, which the SaaS vendor should support.

It is needless to say that the governments would be monitoring the cross border data traffic and would seek clarifications and explanations and for which adequate audit trails and logs are essential.

Identity Management 

Provisioning users and managing their access and authorization permissions for various applications is becoming increasingly complex and enterprises are looking at central identity stores coupled with single sign on to address this problem. With SaaS, this could bring in additional complexity. Most enterprise SaaS application providers offer support for local store and as well as integration with enterprise’s very own identity store.

In case of local identity store, adequate security around the identity store and the process around managing the identity store gains significance. Any lapse in this area could lead to data a compromise in data security.

In cases where integration with enterprise’s own identity store is preferred, then the additional concerns could be in the areas of establishing trust relationships with the SaaS application and securing the federation of user identities between the identity store and the cloud hosted SaaS application.

Conclusion 

Adopting a SaaS application does not absolve the enterprise from governing the information assets associated with such application. The CxOs of the enterprises will still be responsible whether these are managed on-premise or by the SaaS vendor. The SaaS vendors in turn should make sure that they comply with all these needs so as to win the confidence and trust of the enterprise for selling the software services.

Check out my presentation on the same topic on slideshare.