Enterprise Architecture Practice - Capabilities

Enterprise Architecture (EA) function now have an unprecedented chance to lead the way in identifying new business opportunities, thanks to the innovations in the web and mobile technologies and businesses realizing the business advantages of such advancements. EA serves a strategic business purpose by enabling business capabilities to be implemented via IT architecture and related IT delivery processes.

Though Enterprise Architecture is not a very new practice, the maturity level is still not the optimal in most enterprises. Seeing the benefits that the EA function can bring to the table,  many enterprises are attempting to setup the EA practice within, but are in fact struggling to get it right. EA not just science and not just art as well. It is a combination of art and science. Successful EA practice has been found to being able to demonstrate certain key capabilities. In the EA world, there is no such thing as 'one size fits all', as it is highly dependent on the enterprises' business, its objectives, goals, strategies and priorities, which is never the same across enterprises.

While the objective of this blog is to discuss about the key capabilities that the EA function should be able to demonstrate, it is also good to highlight out what EA is not.

What EA is not:

• EA is NOT a project
• EA is NOT about review 
• EA is NOT a one-time activity
• EA is NOT for IT
• EA is NOT a strategy
• EA is NOT all about cost-reduction
• EA is NOT one-man show

A successful EA practice should consider practicing and demonstrating the following key capabilities:

Staying Relevant

As we all know, it is highly unlikely that an architectural solution that works well for one enterprise will work well for another in the same industry domain. This is because each enterprise has its own vision and mission to win over the competition and constantly wish to stand alone in the crowd in certain key areas. Staying relevant helps the EA function in aligning strategic and operational views of business with the underlying technology and service delivery processes. For this reason, the EA practice should strive to understand the vision, mission and strategies of the enterprise and continue to stay aligned to the same, so that the architectural solutions continue to stay relevant for the enterprise.

Technology & Architecture Vision

No doubt that modern enterprise largely depend on technology and in certain cases, the business in fact is driven by technology. Irrespective of whether technology drives the business or not, technology is a key enabler of the business. So, it becomes essential to have a technology vision, which is aligned to the business vision. It is needless to mention that having a vision will not be just enough, and the same shall be driven down to the operational processes and practices. Every architecture and governance process should derive the technology vision as envisaged and so the solutions continue to stay relevant and yield the intended results. The technology vision and strategy shall be such that leverages both new tech innovations and existing capabilities that will enable the business to achieve the target state. 

The goal of the architecture vision is to articulate how the proposed architecture will enable the business goals, respond to the strategic drivers, conform to the principles, and addresses the stakeholder concerns and objectives.

Transforming and automating operations

While leveraging the existing knowledge and resources is key in saving costs, it is important for the EA function to stay on top of the technology and business innovations and explore opportunities of leveraging the same so that the enterprise stays on course of achieving its target mission and vision. This is where the EA teams should consider leveraging Agile approaches, so that the target reference architecture also stays dynamic and relevant. The EA framework shall have an evolution cycle, so as to improve the framework itself and similarly the architecture solutions should also be continually evolved based on feedback and availability of enabling technologies and innovations.

It is needless to mention here that the EA function shall equally consider the 'Business As Usual' as any transformational initiative should not derail the enterprise from achieving its intended mission and vision.

Being the Change Leader

EA is all about bringing change for the good. i.e. EA programs is all about driving the enterprise from its current state to the target reference state, which is nothing but identifying and driving changes to various resources at various levels, so that the target state is achieved. This is yet another key capability that come down to the old adage of building “better, faster, cheaper” systems that provide agility to change or expand capabilities, in response to ever-changing business requirements. EA function leads the planning for these new system and technology capabilities, ensuring the best solutions to the business requirements by providing blueprints and implementation road maps to the design and delivery teams. They also provide a service to the other organizational functions by ensuring compliance of these solutions at critical design and delivery milestones.

Mitigating risk

As the emphasis shifts from cleaning up the legacy of systems and technologies to better planning and governance of new IS and IT initiatives, we see a corresponding shift in the role of the EA practice. The focus shifts from driving out costs to reducing risks associated with new programs, while ensuring timely delivery of new capabilities. 

Every architectural initiatives shall be subject to a risk review and decisions shall be made based on the business value expected out of it. The changing business and regulatory conditions might also impact the solutions and at times could end up the enterprises not being able to realize the intended value out of it. This where the "Fail Fast" approach would help in making the right decisions. Periodic reviews of the change or transformational projects should be conducted with a view to ascertain whether the intended value is not impacted with the current conditions. Thus being able to manage and mitigate the risks well is a key capability that the EA practice should demonstrate.

Overseeing investments

It is natural for enterprises to look for Return on Investments (RoI), as the capital has a cost. The EA practice shall consider the cost of capital and the investment requirements for various change initiatives and work with the related other functions to ensure that the benefits are quantified so as to ensure the investments yield desired returns. In cases where the benefits are not directly quantifiable, the EA team shall identify such indirect benefits derived out of such investments and shall ascertain the monetary value in a best possible manner. 

Governing the architecture

As said earlier, EA function is not a project and it is a continuous function. EA function shall put in place necessary framework to monitor and manage the architectural activities in a constant basis. Business architects in the EA function monitor the project portfolio, while IT architects govern technology solutions, leveraging reference architectures to build the future state in alignment with strategic road maps. The governance principles shall be applied to various architecture activities with an objective to ensure the strategy alignment, risk management, measuring & monitoring, optimal resource utilization.

Integrating people, processes, and technology

Considering the innovation around the areas of web, mobile, big data powered by social media, modern enterprises are looking forward to leverage these to derive maximum business value. In this direction, to stay competitive and relevant to the customer business, most successful organizations are rapidly moving towards the system of engagement architecture supported by digital collaboration platforms and social strategies devised by EA where EA would create an effective social governance model and an overall enterprise strategy. It necessitates a pervasive social layer that spans many different system of records and departments within an organization. Discussion would also enlighten more focus on expanding social footprint by delivering consistent digital experience and utilizing social content and online communities to increase collaboration with customers and other stakeholders.

Principles of Information Governance

With the evolution of tools and technologies around big data, the variety and volume of customer information collected has increased many fold. This also requires the responsible use of such information by the organization. Many countries have promulgated legislations to regulate the use and protection of such information in every organization.

The set of multi-disciplinary structures, policies, processes and controls that are used to manage the customer information and thereby supporting the current and future reglatory, legal and operational requirements make up the Information Governance framework of the organization. Information governance goes beyond retention and disposition to include privacy, access controls, and other compliance issues. It is interesting to note that big data innovators recognize the importance of governance to the success of their projects.

The Principles identify the critical hallmarks of information governance and provide both a standard of conduct for governing information and metrics by which to judge that conduct. In doing so, they give assurance to the public and society at large that organizations of every kind are meeting their responsibilities with respect to the governance of information.

Transmational organizations looking forward to demonstrate the highest level of maturity in the Information Governance design their Governance framework based on the following key principles:

Accountability:

Accountability to is key for the success of any program and on the same lines, for the Information Governance, to be successfull shall have an accountable senior leader, who shall oversee the governance practices and should require regular reporting for monitoring purposes. The organization should adopt policies and procedures to guide its workforce and agents and ensure its program can be audited and continually improved to support the organization’s goals.

An information governance program should at the minimum:

• Establish an information governance structure for program development and implementation
• Designate a qualified accountable person to develop and implement the program
• Document and approve policies and procedures to guide its implementation
• Remediate identified issues
• Enable auditing as a means of demonstrating the organization is meeting its obligations to both internal and external parties

A high maturity organization would demonstrate the following:

• The organization’s senior management and its governing board place great emphasis on the importance of information governance. 
• The records manager directs the records management program and reports to an individual in the senior level of management. 
• The chief information governance officer and the records manager are essential members of the organization’s governing body. 
• The organization’s initial goals related to accountability have been met, and it has an established process to ensure its goals for accountability are routinely reviewed and revised. 

Transparency

An organization’s processes and activities relating to information governance shall be documented in an open and verifiable manner. Documentation shall be available to the organization’s workforce and other appropriate interested parties within any legal or regulatory limitations, and consistent with the organization’s business needs. Transparency of the organization’s governance practices must extend to definitions of appropriate information uses and the processes for ensuring compliance with policies on appropriate information use.

An information governance program includes its information management and information control policies and procedures. To ensure the confidence of interested parties, records documenting the information governance program must themselves adhere to the fundamentals of information management.

At the highest maturity level, an organization should practice and demonstrate the following:

• The organization’s senior management considers transparency as a key component of information governance. 
• The software tools that are in place assist in transparency. 
• Requestors, courts, and other legitimately interested parties are consistently satisfied with the transparency of the processes and the organization’s responses. 
• The organization’s initial goals related to transparency have been met, and it has an established process to ensure its goals for transparency are routinely reviewed and revised. 

Integrity

An information governance program shall be constructed so the information generated by or managed for the organization has a reasonable and suitable guarantee of authenticity and reliability. Integrity of information, which is expected by patients, consumers, stakeholders, and other interested parties such as investors and regulatory agencies, is directly related to the organization’s ability to prove that information is authentic, timely, accurate, and complete. For the healthcare industry, these dimensions of integrity are essential to ensuring trust in information.

For safety, quality of care, and compliance with applicable voluntary, regulatory and legal requirements, integrity of information should include at least the following considerations:

• Adherence to the organization’s policies and procedures
• Appropriate workforce training on information management and governance
• Reliability of information
• Admissibility of records for litigation purposes
• Acceptable audit trails
• Reliability of systems that control information

Transformational organizations, which are at the highest maturity level should demonstrate the following abilities:

• There is a formal, defined process for introducing new record-generating systems, capturing their metadata, and meeting other authenticity requirements, including chain of custody. 
• Integrity controls of records and information are reliably and systematically audited. 
• The organization’s initial goals related to integrity have been met, and it has an established process to ensure its goals for integrity are routinely reviewed and revised. 

Protection

An information governance program shall be constructed to ensure a reasonable level of protection to records and information that are private, confidential, privileged, secret, classified, essential to business continuity, or that otherwise require protection.

Information protection takes multiple forms. First, each system must enable management of security access controls. Only members of the workforce and other authorized parties with the appropriate levels of access or security clearance may access information relevant to their roles or duties. Reliably protecting electronic and physical assets requires use of tools such as user authentication, key card access restrictions, and other relevant measures. This also requires that as the workforce and other authorized parties transition in status or job function, respective level of access is changed immediately to a level appropriate to the new role and duties.

The highly matured organizations would practice and demonstrate the following:

• Executives and/or senior management and other governing bodies (e.g., board of directors) place great value in the protection of information. 
• Audit information is regularly examined, and continuous improvement is undertaken. 
• Inappropriate or inadvertent information disclosure or loss incidents are rare. 
• The organization’s initial goals related to protection have been met, and it has an established process to ensure its goals for protection are routinely reviewed and revised. 

Compliance

An information governance program shall be constructed to comply with applicable laws and other
binding authorities, as well as with the organization’s policies. Every organization should:
Know what information should be entered into its records to demonstrate its activities are being conducted in a lawful manner.

Enter that information into its records in a manner consistent with laws and regulations.
Maintain its information in the manner and for the time prescribed by law or organizational policy.
Develop internal controls to monitor adherence to rules, regulations, and program requirements, thus assessing and ensuring compliance.

The following capabilities when demonstrated will mark the highest maturity level:

• The importance of compliance and the role of records and information in it are clearly recognized at the senior management and governing body levels.
• Auditing and continuous improvement processes are well-established and monitored by senior management. 
• The roles and processes for information management and discovery are integrated, and those processes are well-developed and effective. 
• The organization suffers few or no adverse consequences based on information governance and compliance failures. 
• The organization’s initial goals related to compliance have been met, and it has an established process to ensure its goals for compliance are routinely reviewed and revised. 

Availability

An organization shall maintain records and information in a manner that ensures timely, efficient, and accurate retrieval of needed information.

A successful and responsible organization must have the ability to identify, locate, and retrieve the information required to support its ongoing activities. This information may be used by:

• The healthcare team, patients, and other caregivers Authorized members of the workforce and others authorized consistent with regulations 
• Legal and compliance authorities for discovery and regulatory review purposes
• Internal and external reviewers for purposes including but not limited to: payer audit, financial audit, case management, and quality assurance.

High maturity organizations practice and demonstrate the following:

• The senior management and governing body provide support to continually upgrade the processes that affect records and information availability. 
• There is an organized training and continuous improvement program across the organization. 
• There is a measurable return on investment to the organization as a result of records and information availability. 
• The organization’s initial goals related to availability have been met, and it has an established process to ensure its goals for availability are routinely reviewed and revised. 

Retention

An organization shall maintain its records and information for an appropriate time, taking into account its legal, regulatory, fiscal, operational, and historical requirements.

As part of its retention program, an organization must develop an information retention schedule, which specifies what information must be retained and for what length of time. Retention decisions are based on the type of information, and the organization’s legal, regulatory, fiscal, operational, clinical, role/mission, and historical requirements. Information retention schedules should be reviewed periodically and revised regularly. Some internal changes in the organization such as mergers and acquisitions or lines of business changes, or types of records generated, as well as external events such as legal, regulatory, or fiscal changes, may require revisions.

High maturity organizations consider practising the following:

• Retention is an important item at the senior management and governing body level.
• Retention is looked at holistically and is applied to all information in an organization, not just to official records. 
• Information is consistently retained for appropriate periods of time. 
• The organization’s initial goals related to retention have been met, and it has an established process to ensure its goals for retention are routinely reviewed and revised. 

Disposition

An organization shall provide secure and appropriate disposition for records and information that are no longer required to be maintained by applicable laws and the organization’s policies.

Disposition includes not only destruction, but also any permanent change in custodianship of the information, such as when it is transferred to another party due to a merger or acquisition of another hospital, clinic, or physician practice or when a organization discontinues a practice, service, or other business. In many cases, the appropriate disposition is the destruction of information, in which case the organization should ensure the information is transported and destroyed in a secure and environmentally responsible manner. The organization should document or certify that the information has been destroyed completely and irreversibly when required.

The processes of a high maturity organization should address the following:

• The disposition process covers all records and information in all media. 
• Disposition is assisted by technology and is integrated into all applications, data warehouses, and repositories. 
• Disposition processes are consistently applied and effective. 
• Processes for disposition are regularly evaluated and improved. 
• The organization’s initial goals related to disposition have been met, and it has an established process to ensure its goals for disposition are routinely reviewed and revised.

---

Reference:

1. Information Governance Maturity Model

Architectural Security aspects of BGP/MPLS

The inherent benefits of the MPLS (Multi Protocol Label Switching), is gaining widespread use for providing IP VPN services. With the emerging trend of connected systems, a global enterprise today is well connected with their partners, with MPLS being the preferred choice. Border Gateway Routing Protocol (BGP) is used to interconnect such autonomous systems by exchanging the routing informaiton across such systems. The emergence of Multiprotocol Extension, and other variations of BGP Protocol, has furthered the choice of MPLS VPNs. On the same lines, the security concerns on using such a network is also on the rise. The specific demands of customers in terms of security is also emerging as they experience issues of data breaches and security incidents.

The objective of this blog is not to explain about the BGP / MPLS as such and instead let us examine how the BGP / MPLS addresses the typical security requirements in this blog. The following sections of this blog have been extracted from the RFC 4381 published by Internet Engineering Task Force (IETF) in 2006.


Address Space, Routing, and Traffic Separation

BGP/MPLS allows distinct IP VPNs to use the same address space, which can also be private address space. This is achieved by adding a 64-bit Route Distinguisher (RD) to each IPv4 route, making VPN-unique addresses also unique in the MPLS core. This "extended" address is also called a "VPN-IPv4 address". Thus, customers of a BGP/MPLS IP VPN service do not need to change their current addressing plan. The address space on the CE-PE link (including the peering PE address) is considered part of the VPN address space. Since address space can overlap between VPNs, the CE-PE link addresses can overlap between VPNs. For practical management considerations, SPs typically address CE-PE links from a global pool, maintaining uniqueness across the core.

On the data plane, traffic separation is achieved by the ingress PE pre-pending a VPN-specific label to the packets. The packets with the VPN labels are sent through the core to the egress PE, where the VPN label is used to select the egress VRF. Given the addressing, routing, and traffic separation across an BGP/ MPLS IP VPN core network, it can be assumed that this architecture offers in this respect the same security as a layer-2 VPN. It is not possible to intrude from a VPN or the core into another VPN unless this has been explicitly configured. If and when confidentiality is required, it can be achieved in BGP/ MPLS IP VPNs by overlaying encryption services over the network. However, encryption is not a standard service on BGP/MPLS IP VPNs.

Hiding of the BGP/MPLS IP VPN Core Infrastructure

Service providers and end-customers do not normally want their network topology revealed to the outside. This makes attacks more difficult to execute: If an attacker doesn't know the address of a victim, he can only guess the IP addresses to attack. Since most DoS attacks don't provide direct feedback to the attacker it would be difficult to attack the network. It has to be mentioned specifically that information hiding as such does not provide security. However, in the market this is a perceived requirement. 

With a known IP address, a potential attacker can launch a DoS attack more easily against that device. Therefore, the ideal is to not reveal any information about the internal network to the outside world. This applies to the customer network and the core. A number of additional security measures also have to be taken: most of all, extensive packet filtering. For security reasons, it is recommended for any core network to filter packets from the "outside" (Internet or connected VPNs) destined to the core infrastructure. This makes it very hard to attack the core, although some functionality such as pinging core routers will be lost. Traceroute across the core will still work, since it addresses a destination outside the core.

Being reachable from the Internet automatically exposes a customer network to additional security threats. Appropriate security mechanisms have to be deployed such as firewalls and intrusion detection systems. This is true for any Internet access, over MPLS or direct. A BGP/MPLS IP VPN network with no interconnections to the Internet has security equal to that of FR or ATM VPN networks. With an Internet access from the MPLS cloud, the service provider has to reveal at least one IP address (of the peering PE router) to the next provider, and thus to the outside world.

Resistance to Attacks

To attack an element of a BGP/MPLS IP VPN network, it is first necessary to know the address of the element. The addressing structure of the BGP/MPLS IP VPN core is hidden from the outside world. Thus, an attacker cannot know the IP address of any router in the core to attack. The attacker could guess addresses and send packets to these addresses. However, due to the address separation of MPLS each incoming packet will be treated as belonging to the address space of the customer. Thus, it is impossible to reach an internal router, even by guessing IP addresses.

In the case of a static route that points to an interface, the CE router doesn't need to know any IP addresses of the core network or even of the PE router. This has the disadvantage of needing a more extensive (static) configuration, but is the most secure option. In this case, it is also possible to configure packet filters on the PE interface to deny any packet to the PE interface. This protects the router and the whole core from attack. In all other cases, each CE router needs to know at least the router ID (RID, i.e., peer IP address) of the PE router in the core, and thus has a potential destination for an attack.

A potential attack could be to send an extensive number of routes, or to flood the PE router with routing updates. Both could lead to a DoS, however, not to unauthorised access. To reduce this risk, it is necessary to configure the routing protocol on the PE router to operate as securely as possible. This can be done in various ways: 

• By accepting only routing protocol packets, and only from the CE router. The inbound ACL on each CE interface of the PE router should allow only routing protocol packets from the CE to the PE. 
• By configuring MD5 authentication for routing protocols. This is available for BGP (RFC 2385 [6]), OSPF (RFC 2154 [4]), and RIP2 (RFC 2082 [3]), for example. 

This avoids packets being spoofed from other parts of the customer network than the CE router. It requires the service provider and customer to agree on a shared secret between all CE and PE routers. It is necessary to do this for all VPN customers. It is not sufficient to do this only for the customer with the highest security requirements.

It is theoretically possible to attack the routing protocol port to execute a DoS attack against the PE router. This in turn might have a negative impact on other VPNs on this PE router. For this reason, PE routers must be extremely well secured, especially on their interfaces to CE routers. ACLs must be configured to limit access only to the port(s) of the routing protocol, and only from the CE router.

Label Spoofing

Similar to IP spoofing attacks, where an attacker fakes the source IP address of a packet, it is also theoretically possible to spoof the label of an MPLS packet. For security reasons, a PE router should never accept a packet with a label from a CE router. RFC 3031 [9] specifies: "Therefore, when a labeled packet is received with an invalid incoming label, it MUST be discarded, UNLESS it is determined by some means that forwarding it unlabeled cannot cause any harm."

There remains the possibility to spoof the IP address of a packet being sent to the MPLS core. Since there is strict address separation within the PE router, and each VPN has its own VRF, this can only harm the VPN the spoofed packet originated from; that is, a VPN customer can attack only himself. MPLS doesn't add any security risk here. The Inter-AS and Carrier's Carrier cases are special cases, since on the interfaces between providers typically packets with labels are exchanged. See section 4 for an analysis of these architectures.

There are a number of precautionary measures outlined above that a service provider can use to tighten security of the core, but the security of the BGP/MPLS IP VPN architecture depends on the security of the service provider. If the service provider is not trusted, the only way to fully secure a VPN against attacks from the "inside" of the VPN service is to run IPsec on top, from the CE devices or beyond. This document discussed many aspects of BGP/MPLS IP VPN security. It has to be noted that the overall security of this architecture depends on all components and is determined by the security of the weakest part of the solution.

Governance of Agile Delivery

Introduction

The Agile methodology brings in alternate approach to traditional project management, where success was hard to get. Typically used in software development, Agile methodology help businesses respond to unpredictability. By focusing on the repetition of smaller work cycles as well as the deliverables, agile methodology is described as “iterative” and “incremental”. In waterfall, development teams only have one chance to get each aspect of a project right. In an agile paradigm, every aspect of development viz. requirements, design, etc. is continually revisited. When a team stops and re-evaluates the direction of a project every two weeks, there’s time to change course. Because teams can develop software at the same time they’re gathering requirements, “analysis paralysis” is less likely to impede a team from making progress. Agile development preserves a product’s critical market relevance and ensures a team’s work doesn’t wind up on a shelf, never released. Considering the value delivery that the Agile methodology promises, its adoption has been on the rise and today most organizations, including Government are embracing Agile approaches.


Governance of Agile Delivery


Critics say that Agile methodology is all about working in an unstructured way and for that reason, they believe that governing agile practices is always a challenge. While some of the Agile principles appear to support such criticism, there are many cases where organizations have successfully implemented processes and frameworks towards governance of Agile practices. Agile practitioners believe that because the agile methods are designed to be self-assuring, when practiced right, there exists built-in governance and accountability.


More so, the agile practices are more collaborative and operates continuously, requiring the stakeholders to review and test the deliverables on a continuous basis and helps the team to take alternate course of action as may be needed. Collaborative culture helps resolution of problems quicker and makes decisions are made on time. This helps to have a continuous focus on the value forecast with respect to the business case and manage the risks that may potentially impact on the expected value.


Principles of Governance

The following are the key governance principles for a successful governance of Agile Delivery:

Focus on the value delivery - only do a task if it brings value to the business. This principle also recognizes the timely delivery of a task as the value derived is more likely to deteriorate with the delayed delivery. In case of Agile deliveries, the governance is continuous and at a work unit level. It should also focus on what activity is taking place and the value such task delivers.

Embrace Change - This another principle of Agile and the Governance framework should take this into consideration. This would mean that the decisions or work flows should be flexible enough to change course based on the feedback received. Given that all stakeholders collaborate, decisions should be taken across the table, without putting things on hold and for the purpose, all needed specialists should take part in the reviews.

Decide on the performance metrics - Another key principle of Agile methodology is to 'fail fast and learn quiuckly'. Given that the overall objective is to improve the certainty that the team will deliver a usable product or service of good quality, the teams should be able to identify and implement the right metrics that will accurately indicate the quality of the deliverables and the performance of the team. For example they measure tasks completed; rework they had to perform; the backlog list and the value of the product or service to the business at the end of each iteration. Teams display this information visually, updating it frequently. This makes progress transparent to business users and management. If senior managers require performance information to oversee projects, they define what the ‘must have’ data are. Performance reports for senior management become a task in each iteration and an output of the delivery team.

Collaboration - All stakeholders, including senior management, external assessors, business users and the development team should be partners in quality, and this collaborative approach is an essential change in mindset. The business owner and delivery team defines what ‘quality’ tests they will use and what results are acceptable at the outset of each iteration – the definition of ‘done’. Regular user feedback identifies whether the product or service is providing the expected business value at each stage. External assessors are not gatekeepers; rather they are an integral part of the team. The iterative approach ensures continual reviews and feedback on progress, so external assessors are not just involved at critical points as defined in a traditional project life cycle.

Focus on behaviours and not just processes and documentation - More specifically, the external reviews or assessments will be more effective in providing critical challenge if the assessors have high-end skills, including technical and Agile delivery experience. In addition, they provide better value if they continually review how the team is performing, using observation as their main method of evidence collection. The focus of such external review or assessment shall be on the following:

• the skills and experience of the team;
• the team dynamics – frequency and nature of communication inside and outside of the delivery team, and the level of input to the delivery team from the business;
• the organisational culture – the level of commitment and openness;
• the timing and nature of quality control by the delivery team – the testing and release framework;
• the order in which the team tackled the tasks – prioritisation of actions and deliverables, the amount of actions in the backlog list;
• the way the team changes its activity in response to the results achieved in each iteration; and
• the value of outputs to the business.

IBM's Disciplined Agile Delivery Methodology


IBM believes Agile delivery allows it to continually issue new capabilities that meet user needs. It usually introduces software as part of a wider business change project so, to keep both in step, it has developed several Agile project methodologies. Disciplined Agile Delivery is a hybrid method that can be applied by a large number of teams working on the same project at the same time. The image below shows the Disciplined Agile Delivery life cycle. It starts with a few short iterations that allow the team and its stakeholders to identify the initial requirements, develop the architecture and agree a release plan. IBM also uses this to determine the system level properties and characteristics – the non-functional requirements. There are iterations after the business owner has decided that the system has sufficient functionality. These additional iterations are necessary for IBM to support the operation and maintenance of the solution once it is in service.



In contrast to the traditional approach of looking at outputs, plans, resourcing and how a project is organised, external assessors should focus on outcomes, prioritisation of work and team dynamics. The most useful indicators of success are how the teams are organising the delivery of an operational service or capability and what Agile behaviours and practices are used. Areas for assessment include whether:
system level issues (security, availability) are addressed within the iterations;

• short- and longer-term planning exists;
• the stakeholders have a shared vision;
• there is continuous integration; and
• the team has the right people

---

Reference:

National Audit Office's Review on Governance of Agile Delivery

Sustaining Successful IT Governance Environment

A tremendous amount of importance is being given to governance, risk, and compliance (GRC), ans thus IT governance is becoming a necessity in today's business context. There is strong pressure on senior management and the Board members to have a good understanding of their IT systems and the controls that are in place to avoid things such as fraud and security breaches. As the global corporate and economic climate continues to shift, businesses need to be prepared to anticipate, respond to, and mitigate risk with flexible processes that can be adapted to any methodology. This calls for assessing and continuously monitoring of the IT Governance as it operates in an organization.

IT governance represents a continuous journey (not an end state in itself), which focuses on sustaining value and confidence across the business functions. Many companies start on a short term approach and focus on the compliance component of IT governance, without developing a balanced longer term approach consisting of both a top down framework and roadmap together with bottom up implementation to address the broad range of IT governance issues and opportunities in a planned, coordinated, prioritized and cost effective manner. 

Getting it Right First

Different IT governance stake holders need different features so the solution needs to be structured, taylored and feature risk management. Because process is at the heart of IT Governance the solutions has to be process centric but also support all other perspectives, organisations, technology, application, infrastructure, etc. Being process centric, IT Governance aspects should be integrated into the existing process framework of an organization, so that it becomes real, operational and sustainable.

It is important to get the IT Governance pieces well integrated and have the same operational first. To have an effective and operational IT Governance program, at the minimum, the following should be taken care of.

• Executive Commitment - The Board and the Executive Leadership Team are committed to implementing and sustaining a robust Governance environment.
• Do Homework - Educate yourself on past, current and emerging best practices.
• Gather knowledge - Develop, adopt, integrate, leverage and tailor current and emerging best practices models, frameworks and standards to make them work for the enterprise - create an integrated IT governance framework and roadmap for your organization.
• Sell it - Market the IT governance value propositions to the organization and communicate its goals and objectives.
• Assess Current State - Assess the “current state” of the level of IT governance maturity and identify gaps. 
• Define Future State - Based on the knowledge gathered, develop a “future state” IT governance blueprint.
• Implementation plan - Come up with an implementation plan by breaking down the components into well defined work packages and assign an ownership and responsibility.
• Roll out - Implement a scalable and flexible governance policy and process.

Continuous Improvement

There could not be a second thought in that the IT Governance needs to be sustainable by putting in place a lifecycle for continuous improvement.  IT Governance like any other process framework need continuous improvement in line with the changing business and technology environment and to ensure that the desired benefits are realized for ever. While the improvement cycle can be as simple as that of Demings PDCA, ISACA has suggested a seven step cycle as below:

• What are the Drivers?
• Where are we now?
• Where do we want to be?
• What needs to be done?
• How do we get there?
• Did we get there?
• How do we keep the momentum going?

At the minimum, organizations should address the following questions to have the IT Governance continuously improved and thus sustained:

Image Source: The Advisory Council

With an integrated IT Governance framework in place, these improvement steps cannot be performed in isolation for the IT Governance function alone. Such improvement life cycle shall be applied to each of the functions, like Service Management, Asset Management, People & Project Management, and IT Portfolio Investment Management. The improvement life cycle shall thus at such levels and when such functions improve and deliver the desired results and value, IT Governance in turn will also be delivering. 

How much is enough?

As a process, operational governance must be carried out by one or more people. Even though it is useful to treat governance as outside the day-to-day operations of an organization, those carrying out the governance process may or may not belong to the governed organization. Even so, those who are carrying out the governance process must be concerned with certain external forces on the organizations as well. These external forces could be External Policies, External Standards, Government Regulations, etc. 

It is needless to mention that continuous improvement of IT Governance requires investment and it is equally important to justify the investment in continuous improvement pays back. Thus, the organization should know how much improvement is enough for them and accordingly focus its resources for this activity. However, knowing how much of IT Governance is enough is a key challenge, which will depend on the following factors:

• Investment in IT (capital and expense), strategic value
• Management philosophy and policy (e.g. mandatory and discretionary)
• Program/Project and/or Operational visibility
• Complexity, scope, size and duration of initiatives
• Number of interfaces an integration requirements
• Degree of risk
• Speed of required implementation
• Number of organizations, departments, locations and resources involved
• Customer or sponsor requirements
• Type and location of outsourcing (e.g. domestic, international)
• Regulatory compliance 
• Level of security required
• Degree of accountability desired and audit-ability required (per external auditors)
• Management Control Policies and Guidelines

Key Principles

To sustain and continue to make progress on the journey to achieving higher levels of IT maturity, an organization should adopt select principles from managing and accelerating change and transformation, which include the following key elements:

• Proactively Design and Manage the IT Governance Program. Requires executive management sponsorship, an executive champion and creating a shared vision that is pragmatic, achievable, marketable, beneficial and measurable. Link goals, objectives and strategies to the vision and performance metrics and evaluations.
• Mobilize Commitment and Provide the Right Incentives. There is a strong commitment to the change from key senior managers, professionals and other relevant constituents. They are committed to make it happen, make it work and invest their attention and energy for the benefit of the enterprise as a whole. Create a multi-disciplinary empowered Tiger Team representing all key constituents to collaborate, develop, market and coordinate execution in their respective areas of influence and responsibility. 
• Make Tradeoffs and Choices and Clarify Escalation and Exception Decisions. IT governance is complex, continuous and requires tradeoffs and choices, which impact resources, costs, priorities, level of detail required, who approves choices, to whom are issues escalated, etc. At the end of the day, a key question that must be answered is, “When is enough, enough?” 
• Making Change Last, Assign Ownership and Accountability. Change is reinforced, supported, rewarded, communicated ( through the Web and Intranet), recognized and championed by owners who are accountable to facilitate the change so that it endures and flourishes throughout the organization.
• Monitoring Progress, Consistent Processes, Technology and Learning. Develop/ adapt common policies, practices, processes and technologies which are repeatable across the IT Governance landscape and enable (not hinder) progress, learning and best practice benchmarking. Make IT governance an objective in the periodic performance evaluation system of key employees and reward significant and sustainable progress and achievements. 

People often think they have a choice between "governance" and "no governance," but in reality the choice is between "good governance" and "bad governance." Every organization has a framework of decision-making and some set of often unstated measures. The needs of the business and the role of IT evolve; these unintentional governance solutions do not. Good governance is intentional, and it takes effort and attention. The operational perspective described in this article provides an approach for doing governance well.

IT Governance For Small Businesses - Constraints

There is a perception that IT Governance best suits for large organizations and small organizations tend to ignore it considering the efforts and resources that is required in practicing the IT Governance within. But IT Governance is equally important for smaller organizations as well, so that the IT function however small it is deliver maximum value for the business and at the same time to keep the risk exposure to the minimum. Existing frameworks like COBIT are too extensive for small businesses to use in implementing IT governance. These frameworks however are too complex and costly to implement and small businesses may consider it a bigger battle to implement and manage such framework.


ISACA however recommends to take an evolutive approach and thus take smaller steps first and let it evolve. Small businesses should convert the high-level concept of governance into practical and easy to implement best practices. The resource pools available with the small businesses will be a lot smaller and even outsourcing might prove expensive, considering the business volume and thus establishing an RoI on implementing IT Governance could be a bigger challenge.


It is not just the resources and cost, there are certain other characteristics of small businesses, which come in way of implementing an IT Governance. Here are some such characteristics, which an IT Governance framework designed for a small business should take into consideration.


Smaller or no Board of Directors

Many small businesses are closely held and thus could be a family business or private limited company with a small number of Directors on the Board. Having an Independent Director or a Director with IT background on the board is a big ask. This will leave the concentration of IT decision making with few or even single individual, which could be the CEO or the owner himself. IT savvy business owners or CEOs tend to use or leverage IT more for their business and thus have some degree of adoption of standards, practices and frameworks. In such cases, the choice of technology, standards, practices, etc are most likely limited to the knowledge levels of the owner or CEO and they don't take a leap forward into unfamiliar areas, which will call for more resources in evaluating and establishing the RoI for the same.

Organization Structure

One of the first step in implementing the IT Governance in an organization is to get an IT Strategy Committee and an IT Steering Committee with representation from different functions and from the Board. Small businesses do not have the extensive management structures to have such committee(s). The organization structure with small business are not as extensive as that of large organizations and as such enforcing separation of duties may not be feasible at all. For instance, the Finance Manager of a small business will also perform the function of IT procurement with minimal support from IT Administrators. Similarly, having a separate CIO could be a bigger ask for a small businesses as the costs for having such resources does not warrant the return.

Smaller IT departments

Having a fully functional IT department is a big investment for a small business. Thanks to the cloud trend and software as a service, this is a challenge even the IT departments in large organizations are facing. Cloud based services like Google Apps for business and Microsoft's Office 365, coupled with various specific purpose software as a service, it is becoming a lot easier for the businesses to get its IT up and running with least help from IT experts. This characteristic of a small business leads to a situation where a non-IT staff might have to take up the IT Governance initiative, which obviously has a challenge within as such staff might not comprehend the nuances of the Governance practices and jargon.

Lack of complementing frameworks

IT Governance  framework generally relies on various other practices or frameworks practiced in an organization. For instance ITIL, Enterprise Risk Management, ISO, CMMI, etc are some such standards or frameworks, the existence of which makes adoption of an IT Governance framework a bit seamless. In a small business existence of such standards is highly unlikely. Small businesses need an IT governance framework that is simpler, self containing and easier to implement, and only contain controls that are not dependent on a control practice of a different standard or practice.

Information security

While small business are not the target of hackers or attackers, the risk of information security always remained. For obvious reasons that arise out of the characteristics listed here, small businesses could not see the return on investment in information security. For that matter, small business do not have a formal risk management practice. They, typically, do not possess some of the basic elements of security management like information security policies, backup and disaster recovery, security awareness and up-to-date anti-virus protection. An IT governance framework aimed at small businesses will have to include a strong emphasis on information security and address the common security risks affecting small businesses.

Resources & Tools

Use of sophisticated software applications make implementation and practicing IT Governance easier, but it calls for heavy investment, which is beyond the reach for small businesses. For instance, Performance Evaluation of various IT resources call for collection of data and come up with various metrics that can be used to benchmark and as well measure the performance of IT resources and functions. This is made easier by using automated tools and depending on manual methods could prove cumbersome and data inaccuracy.
Because of the lack of financial and technical resources, small businesses cannot make use of such automated tools or software systems for the purpose.


Though the above list is not exhaustive, what are listed above are the ones that can be considered as key constraints for an IT Governance framework for the small business to address. There is no one solution fits all even for large organizations. The IT Governance framework has to be designed, created and managed as relevant for each organization. That includes even a small business. While one may pick and choose controls from various frameworks and tailor them to suit the specific small or medium business. The framework should however provide for evolution, so that the same can improve based on feedback from the practice.

REST Services - Security Best Practices

As most of us know, REST (Representational State Transfer) is an architectural principle and is gaining increasing reckoning amongst architects for the inherent advantages that it offers. REST does recommend the use of standards such as HTTP, URI, XML and JSON and formats such as GIF, MPEG, etc. Twitter, iPhone apps, Google Maps, and Amazon Web Services (AWS) demonstrate heavy use of REST services. The basic tenets of REST is statelessness and is all about utilizing the HTTP commands GET, PUT, POST, DELETE as outlined in the HTTP RFC.


Obviously, Architects see some key advantages with the REST services, and so REST implementation becomes an important consideration in responsive, service oriented applications. Let us have a recap of some of the key advantages as below:

• The resources can be uniquely identified using URI and facilitates interconnection of these resources.
• Resource manipulation is accomplished using the standard HTTP verbs, viz GET, PUT, POST, DELETE
• The data payload is minimal and thus offers the capacity and efficiency benefits.
• Easier implementation offers shorter learning curve, maintainability and time to market advantage.
• Increased support from the JavaScript offers the client side computing benefits and thus improve the responsiveness.

Needless to mention, there are certain disadvantages too with the REST Services and here are some:

• Prone for same level of threats and vulnerabilities as the HTTP and Web
• Improper use of the HTTP commands could lead to problems and complicate the design.
• Relies on very few standards.

Some of the security challenges with REST Service implementations are outlined below:

Chained trust is challenging for web service implementations and the situation is no different with REST. Unlike in case of SOAP, standards like WS-Security, SAML cannot be used in case of REST services. This call for relying on a combination security implementations which are specific to different implementations. Here are some such security implementations, which in combination may help overcome this concern:

• Use Digital Certificates for authenticating the server and the user. 
• Pass the user's identity from server to server and necessary validation and authorization at the data source.

Cross site request forgery (CSRF) attacks, which attempt to force an authenticated user to execute functionality without their knowledge. Being stateless, REST is inherently vulnerable to CSRF attacks. The work arounds for this security concern are:

• Use of a custom header - Setting a custom header such as X-XSRF header is known to be a solution for this concern. The endpoints receiving the REST service requests would reject or drop such requests if the intended custom header is not part of the request. It is to be noted that this is not a fool proof technique, but at the same time offers some bit of protection than nothing.
• Another approach is to deviate from the basic tenets of REST and maintaining state, in which case a token can be generated and maintained to authenticate the requests, so that requests carrying an invalid or no tokens can be dropped or rejected.

While the above are just an example of the concerns, REST services being based on HTTP specifications is prone to all the security vulnerabilities as that of a web application. Thus REST implementation while it is the easier choice due to its advantages listed above, should also be implemented with due considerations to some or all of the following security best practices:

• All data must be sent over HTTPS and this will ensure securing of the data in transit.
• Use of PKI or HTTP Digest Authentication for authentication.
• Always perform authorization for every request upon receipt. 
• Scan HTTP headers, query strings and POST data and look for reasons to reject a request.
• Don't combine multiple resources with a single URI, always uniquely identify each resource, so that the security implementation can be simple and relevant to the specific resource.
• Always perform validation of the JSON / XML data.
• Ensure appropriate use of the HTTP commands for managing the resources and enable selective restriction of these commands.
• Design URIs to be persistent. If a URI needs to change, honor the old URI and issue a redirect to the client.
• Caching should generally be avoided where possible and sensitive data should never be cached.
• When developing REST solutions, care needs to be taken not to create URIs that contain sensitive information. 
• The requester should be authenticated and authorized prior to completing an access control decision. 
• All access control decisions shall be logged. 
• Code as if protecting the application.

Here are certain useful readings on securing the REST services:

• REST vs. SOAP: How to choose the best Web service
• Enabling Message Security for RESTful Services
• Securing RESTful Web Services with OAuth2
• Securing RESTful services
• REST Assessment Cheat Sheet
• Configuring Spring Security for a RESTful Web Services
• Comparison of Security Techniques for RESTful Services

Webservice Security Standards

SOA adoption is on the rise and Webservices is predominantly used for its implementation. Webservice messages are sent across the network in an XML format defined by the W3C SOAP specification. Webservices have come a long way and has sufficiently matured to offer the required tenets especially on the security domain. In this blog let us have a quick look at the available standards with respect to the security dimensions and look at how the related security requirements are addressed.

Secure Messaging

• WS-Security - This specification was originally developed by IBM, Microsoft and Verisgn and OASIS (Organization for the Advancement of Structured Information Standards) continued the work on this standard. This standard addresses the Integrity and Confidentiality requirements of the webservice messages. The specification describes the signing, encrypting of the SOAP messages and also about attaching security tokens. Various signature formats and encryption algorithms are supported. The security tokens supported include: X.509 Certificates, Kerberos tickets, User ID/Password credentials, SAML assertions and custom tokens. Due to the increased size of the SOAP messages and the cryptographic requirements, this standard requires significantly higher compute resources and network bandwidth.
• SSL/TLS - SSL was developed by Netscape Communications Corporation in 1994 to secure transactions over the World Wide Web. Soon after, the Internet Engineering Task Force (IETF) began work to develop a standard protocol that provided the same functionality. They used SSL 3.0 as the basis for that work, which became the TLS protocol. In applications design, TLS is usually implemented on top of any of the Transport Layer protocols, encapsulating the application-specific protocols such as HTTP, FTP, SMTP, NNTP and XMPP. Historically it has been used primarily with reliable transport protocols such as the Transmission Control Protocol (TCP). This standard helps address the Strong authentication, message privacy and integrity requirements.

Resource Protection

• XACML - eXtensible Access Control Markup Language defines a declarative access control policy language implemented in XML and a processing model describing how to evaluate access requests. Version 3.0 of this standard has been published by OASIS in January 2013. The new features of the latest version of this standard include: Multiple Decision Profile, Delegation, Obligation Expressions, Advice Expressions and Policy Combination Algorithms.While there are many ways the base language can be extended, many environments will not need to do so. The standard language already supports a wide variety of data types, functions, and rules about combining the results of different policies. In addition to this, there are already standards groups working on extensions and profiles that will hook XACML into other standards like SAML and LDAP, which will increase the number of ways that XACML can be used.
• XrML - Developed by Content Guard, a subsidiary of Xerox, and supported by Microsoft, eXtensible Rights Markup Language would provide a universal method for specifying rights and issuing conditions associated with the use and protection of content in a digital rights management system. XrML licenses can be attached to WS-Security in the form of tokens. XACML and XrML both deal with authorization. They share requirements from many of the same application domains. Both share the same concepts but use different terms. Both are based on XML Schema. Microsoft's Active Directory Rights Management Services (AD RMS) uses the eXtensible rights Markup Language (XrML) in licenses, certificates, and templates to identify digital content and the rights and conditions that govern use of that content.
• RBAC, ABAC - Similar to XrML, RBAC and ABAC are established approaches to define and implement Role Based Access Control and Attribute Based Access Controls and can be attached to WS-Security as tokens. The use of RBAC or ABAC to manage user privileges (computer permissions) within a single system or application is widely accepted as a best practice.
• EPAL - The Enterprise Privacy Authorization Language (EPAL) is an interoperability language for exchanging privacy policy in a structured format between applications and can be leveraged for addressing the privacy concerns with the SOAP messages. An EPAL policy categorizes the data an enterprise holds and the rules which govern the usage of data of each category. Since EPAL is designed to capture privacy policies in many areas of responsibility, the language cannot predefine the elements of a privacy policy. Therefore, EPAL provides a mechanism for defining the elements which are used to build the policy.

Negotiation of Contracts

• ebXML - e-business XML is a modular suite of standards advanced by OASIS and UNCEFACT and approved as ISO 15000. While the ebXML standards seek to provide formal XML-enabled mechanisms that can be implemented directly, the ebXML architecture is focused on concepts and methodologies that can be more broadly applied to allow practitioners to better implement e-business solutions. ebXML provides companies with a standard method to exchange business messages, conduct trading relationships, communicate data in common terms and define and register business processes. A CPA (Collaboration Protocol Agreement) document is the intersection of two CPP documents, and describes the formal relationship between two parties.
• SWSA - The SWSA(Semantic Web Services Architecture) interoperability architecture covers the support functions to be accomplished by Semantic Web agents (service providers, requestors, and middle agents). While not all operational environments will find it necessary to support all functions to the same degree, the distributed functions to be addressed by this architecture to include: Dynamic Service Discovery, Service Engagement (Negotiating & Contracting), Service Process Enactment & Management, Semantic Web Community Support Services, Semantic Web Service Lifecycle & Resource Management Services and Cross Cutting Issues.

Trust Management

• WS-Trust - The goal of WS-Trust is to enable applications to construct trusted SOAP message exchanges. This trust is represented through the exchange and brokering of security tokens. This specification provides a protocol agnostic way to issue, renew, and validate these security tokens. The Web service security model defined in WS-Trust is based on a process in which a Web service can require that an incoming message prove a set of claims (e.g., name, key, permission, capability, etc.). If a message arrives without having the required proof of claims, the service SHOULD ignore or reject the message. A service can indicate its required claims and related information in its policy as described by WS-Policy and WS-PolicyAttachment specifications.
• XKMS - XML Key Management Specification is a protocol developed by W3C which describes the distribution and registration of public keys. Services can access an XKMS compliant server in order to receive updated key information for encryption and authentication. The XML Key Management Specification (XKMS) allows for easy management of the security infrastructure, while the Security Assertion Markup Language (SAML) makes trust portable. SAML provides a mechanism for transferring assertions about authentication of entities between various cooperating entities without forcing them to lose ownership of the information.
• SAML - Security Assertion Markup Language is a product of the OASIS Security Services Technical Committee intended for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider. SAML allows business entities to make assertions regarding the identity, attributes, and entitlements of a subject (an entity that is often a human user) to other entities, such as a partner company or another enterprise application. SAML specifies three components: assertions, protocol, and binding. There are three assertions: authentication, attribute, and authorization. Authentication assertion validates the user's identity. Attribute assertion contains specific information about the user. And authorization assertion identifies what the user is authorized to do. Protocol defines how SAML asks for and receives assertions. Binding defines how SAML message exchanges are mapped to Simple Object Access Protocol (SOAP) exchanges.
• WS-Federation - WS-Federation extends the WS-Security, WS-Trust and WS-SecurityPolicy by describing how the claim transformation model inherent in security token exchanges can enable richer trust relationships and advanced federation of services. A fundamental goal of WS-Federation is to simplify the development of federated services through cross-realm communication and management of Federation Services by re-using the WS-Trust Security Token Service model and protocol. A variety of Federation Services (e.g. Authentication, Authorization, Attribute and Pseudonym Services) can be developed as variations of the base Security Token Service. 

Security properties

• WS-Policy, WS-SecurityPolicy - WS-Policy represents a set of specifications that describe the capabilities and constraints of the security policies on intermediaries and end points and how to associate policies with services and end points. Web Services Policy is a machine-readable language for representing these Web service capabilities and requirements as policies. Policy makes it possible for providers to represent such capabilities and requirements in a machine-readable form. A policy-aware client uses a policy to determine whether one of these policy alternatives (i.e. the conditions for an interaction) can be met in order to interact with the associated Web Service. Such clients may choose any of these policy alternatives and must choose exactly one of them for a successful Web service interaction. Clients may choose a different policy alternative for a subsequent interaction.
• WS-ReliableMessaging, WS-Reliability - WS-ReliableMessaging, was originally written by BEA Systems, Microsoft, IBM, and Tibco and later submitted to the OASIS Web Services Reliable Exchange (WS-RX) Technical Committee for adoption and approval.Prior to WS-ReliableMessaging, OASIS produced a competing standard WS-Reliability that was supported by a coalition of vendors. The protocol allows endpoints to meet the guarantee for the delivery assurances namely, Atmost Once, Atleast Once, Exactly Once and In Order. Persistence considerations related to an endpoint's ability to satisfy the delivery assurances are the responsibility of the implementation and do not affect the wire protocol.

Strategies for Information Governance

No, we are not discussing about IT governance or Data Governance either. It is about Information Governance. Information is fast becoming the currency of the business organizations and it is an important asset that need to be protected, managed and governed. Physical records are giving way in favor of digital information and it is growing and moving beyond the boundaries of the enterprise. This opens up a new set of challenges in realizing the business value and managing the associated risks. To add to that a whole set of new and evolving regulatory requirements escalate the risks of privacy, security and retention. Now to understand what is Information Governance let us look at how Gartner defines it:

“The specification of decision rights and an accountability framework to encourage desirable behavior in the valuation, creation, storage, use, archival and deletion of information. It includes the processes, roles, standards and metrics that ensure the effective and efficient use of information in enabling an organization to achieve its goals.”

Looking at the above definition, we can say that the Information Governance is a framework for managing information life cycle from its creation through its deletion and defining accountability, retention, protection and quality aspects around the same. Obviously the framework should comprise of processes, standards, roles & responsibilities, metrics and tools and technology for effective and efficient use of the information. The framework should be in line with the strategies of the organization for Information Governance. So it is important to establish the strategies first and then build the framework around it.

Obviously the Information Governance Strategies shall be formed with due consideration to the following aspects of Information:

Classification: Information classification is one of the most crucial elements of an effective information governance process and yet it’s also the one that many organizations fail to implement well. In its simplest terms, Information classification is the process of categorizing information based on its level of sensitivity, perceived business value and its retention needs. While information classification based on sensitivity is mostly prevalent as most of the Information Security frameworks demand, for an effective and efficient information governance, the classification should represent the retention needs and the business value in addition to sensitivity. When done properly, the classification of information helps an organization determine the most appropriate level of safeguards, controls and usage guidelines that need to be in place. Organizations should be aware that data classification may change throughout the life cycle. It's important for data stewards to re-evaluate the classification of information on a regular basis, based on changes to regulations and contractual obligations, as well as changes in the use of the data or its value to the company.

Protection: Protection of data is an important Element of the information governance framework. Data security breaches now appear to be headline news almost on a weekly basis. The consequences can be
disastrous as organisations’ bottom line and reputation are impacted. Information management and protection is undoubtedly moving in keeping with organisational changes. A planned governance structure
for information allows organisations to support business expansion, while meeting regulatory and personal data protection laws. 

Retention: Organizations are obligated to respond to various information requests, be it litigation, audit or investigation. There are numerous legislations in various countries requiring retention of information for a certain period to be used as evidences. Certain countries have legislations that require non persistence of information, i.e. certain class of information not to be persisted for privacy reasons. Effectively balancing such complex retention requirements depends on proper identification and classification of the information and use of appropriate tools and technology.

Roles & Accountability: Historically, establishing robust information management was considered an IT challenge. The CIOs were expected to deliver the appropriate technology to support critical information reporting and management, and the CISOs, who are mostly aligned with IT functions, were expected to protect the information assets. This does not absolve the business functionaries from the accountability of the information that they create and manage. IT is just a facilitator and it is the business who owns and be responsible for the information throughout its life cycle. The overall requirements of any information asset must be specified, ultimately, by the business people who define, understand and own the process that handles its usage. 

Collaboration: The people who staff the functions that produce and use the information are the people who know its value, can point out the current version of documents, should know how long a given document or set of data is going to be useful from a business continuity perspective. Thus it is very important that their knowledge on these aspects of information is considered while formulating the information governance strategies. Committed involvement from every employee and an effective communication amongst all of them is the key in building a successful information governance framework. Continued collaboration of all the business and IT functions is also essential in sustaining the information governance program in the organization, so that various attributes that determine the information classification, its usage and its business value are constantly aligned to the changing landscape of regulatory and business needs.

Quality & Integrity: As the information is becoming a key asset of an organization and that many decisions are based on the information at hand, it is important that the quality and integrity of the information to be at the highest level, so that such decisions do not go against the organization. Appropriate processes or techniques to validate the quality and integrity of the information shall be put in place and those involved in the creation or discovery of the information shall ensure that appropriate checks are performed and ensure that the information so created is reliable.

Information Governance is a combination of business practices, technology and human capital for meeting the compliance, legal, regulatory, security requirements, and organizational goals of an entity. Information governance provides a means to protect, access, and otherwise manage data and transform it into useful information. While applying best practices such as physical and electronic security measures as well as creating policies for the disposition of data are critical to implementing an information governance strategy, available technology solutions and services can play a key role in several areas.

Colocation - Key Considerations for Selection of Service Provider

Increasing number of organizations are shifting towards Colocating the data centers as they see the inherent benefits like efficiency, security and other shared managed services. Colocation is offered as a service based on the standards, policies, procedures, people and the data centre infrastructure. The user experience depends on the quality of each of these components that form part of the service. The type of provider also drives the end-user experience because you get what you pay for. Given the significant benefits of colocation, CIOs cannot just ignore this as an option, but need to look for reliable facilities that upholds the needs of the organization.

The benefits of going for colocation service include effective use of capital and having higher quality facilities through power redundancy, cooling, and scalability/growth. Choosing a colocation provider is a strategic business decision that evolves from thoughtful consideration certain key parameters. More over, the partnership with the colocation service provider need a multi-year commitment from both. Listed below are some of the key considerations that help the CIOs to make a well thought out decision on choosing the right provider. The list below however is in no order of priority.

Customer & Partner Considerations
Many tend to focus on the organization's IT needs and base the decision to colocate and the choice of the service provider on such internal design parameters. However, the CIOs also have to consider the strategies of their customers and partners . For instance, in case of highly interconnected and collaborative partner systems, the DR sites need to have connectivity with the DR sites of the partner systems as well. If the service goes down customers will easily become frustrated with the company, especially if they are in a new market and are not long-time clients.

Power and capacity planning
The power supply is a key component of the shared services that the colocation service provider offers. Needless to say that it is a vital that the data center is supported with a scalable and reliable power supply in order to keep up the infrastructure components. The supplier should focus on the future needs of the customers and perform proactive capacity planning so that they are prepared to support the scalability needs of the organizaiton.

Resiliency
Designing and building a reliable and resilient data center would call for heavy investment and smaller organizations would find it difficult to justify the RoI for such investments. However, colocation service offers this benefit as the provider would however will be sharing the cost with multiple service consumers. However careful evaluation of the design and architecture elements that will contribute towards ensuring reliability and resiliency of the service is essential in making a decision on the choice of service provider. A carefull review of the SLA of any colocation provider is also very important to ensure that the service provider assures commits for the current future investments to support this need.

Security and technical advancement
With colocation, the organization is leaving its servers, equipments and the more precious data assets in the custody of the service provider, which usually is outside the physical security boundary of the organization. Thus, physical security to the premises and the assets hosted there in is an important component of the colocation service and needs a careful consideration and evaluation. A comprehensive security, beyond the guard, ensuring data protection at all times is what is required. Additional factors of security involving evolving technologies like biometric, card readers, keypad or electronic locks as well as surveilance cameras should form part of the security investments.

Network connectivity and proximity
Like reliability and resiliency, network performance is a key customer service issue, not just a technology issue. An ineffective interconnect setup or limited network system can lead to disruptions in the business operations. It would also matter much to ascertain the network latency associated with connectivity with partner systems. In most cases, if there is a need to have heavy amount of data or information exchanged with a particular partner system, it would be beneficial to have the data center closer to that of the partner's so that the latency between such centers could be as much lower, leading to faster and efficient communication. Network performance issues can have a tangible financial impact to the bottom line. It is usual that the colocation providers offer diverse options for internet access and a careful selection of a primary and redundant internet service providers is essential. 

Technology & support
The colocation service provider should be implementing standard facility design elements and integrating proven technologies so that better power and cooling capacities is achieved. The provider should also have the demonstrated expertise in facilitating flexible deployment of higher density solutions in an on-demand model. Despite the colocation arrangement, the IT heads of the organization are still responsible in addressing the business needs and as such a careful evaluation of the standards and practices that the provider follows in keeping up with the technology and trends is very much essential.

While most providers offer on-site 24/7 technical support, the skill sets in the offer could vary. Again the organization may demand a specialized skill, which the service provider might not be able to support. As such, it is important to compare the skills needed vis-a-vis the skills on the offer and make appropriate decisions. Similarly, the maintenance windows of the service provider for certain support services could be different from that the organization would want. Thus this is another component that needs careful consideration.

Flexible commercial terms
While the key benefit of outsourcing is the shift from the capital investment to operational expenditure, CIOs might endup spending way higher unless a carefull evaluation of the commercials attached to each of the specific service or component that forms part of the colocation service. Ideal cloud service provider would let the customer to pick and choose the components and also offer multiple and flexible billing options to choose. A careful choice is required to ensure to optimize the value realization out of the colocation engagement.

Locational Constraints
Despite having on-site technical support, there would be emergencies needing experts to visit the data center to physically visit the location and work on solutions. As such, the geographical location of the data center(s) does matter to the organization and needs careful consideration. Similarly, local issues like frequent political unrests, frequency of natural disasters in the region, proximity to the airport, etc need to be considered. For instance if the data center is located in a flood prone area, there is a high risk of the data center services getting affected.

Regulatory Compliance
Various countries and states have legislations that could have an impact on the data or other assets that is being housed at the colocated data center.  For instance, UK and US have privacy and security legislations that have an impact on the way the information is stored, processed or disseminated. It is also beneficial to have an insider’s view and legal opinions where needed.  A provider located in a flood plain or an area prone to hurricanes creates unnecessary risk for the business.

Auditability
Given that most businesses are technology driven, the regulatory and legal needs warrant that the audit of systems and facilities and thus calling for appropriate arrangement with the provider to support this need. The  provider may be requested to share copy(ies) of a SAS 70, SOC 2 or such other audit report, which represents a third-party validation of internal process and controls.

Costs
Cost is also an equally important aspect to consider. However, many times, it may not make sense in just considering the cost and instead it should be considered in line with the tangible and intangible value that could be realized out of colocation. For instance, better network performance would benefit as there could be faster and increased acceptance of the systems by the customers and partners resulting in expanding the market. Similarly, better security services might protect the organization from potential liabilities that may arise in future on account of security breaches. Thus the lowest cost isn’t necessarily the best for the business. Lack of support, insufficient product lines or unreliable data center facilities can end up being very costly later on. 

Green IT
The power consumption of a data center is way higher than a regular office premise. Colocation by itself would contribute towards optimizing the energy consumption as it would be a consolidated specially built facility shared amongst many. However, it is worth exploring the measures that the provider has in place towards conserving energy. and such other green practices in place.

While the above considerations are generic, certain other considerations might be vital for some organizations depending on their business nature and priorities. This list can be further updated based on the feedback and comments from the readers.

Software Quality Attributes: Trade-off anaysis

We all know that the Software Quality is not just about meeting the Functional Requirements, but also about the extent of the software meeting a combination of quality attributes. Building a quality software will requires much attention to be paid to identifying and prioritizing the quality attributes and design &  build the software to adhere those. Again, going by the saying "you cannot manage what you cannot measure", it is also important to design the software with the ability to collect metrics around these quality attributes, so that the degree to which the end product satisfies the specific quality attribute can be measured and monitored.

It has always remained as a challenge for the software architects or designers in coming up with the right mix of the quality attributes with appropriate priority. This is further complicated as these attributes are highly interlinked as a higher priority on one would result in an adverse impact on another. Here is a sample matrix showing the inter-dependencies of some of the software quality metrics.

	Avail- ability	Effici- ency	Flexi- bility	Inte- grity	Inter-oper-ability	Main-tain-ability	Port-ability	Reli-ability	Reus-ability	Rob-ust-ness	Test-ability
Avail-ability								+		+
Effici- ency			-		-	-	-	-		-	-
Flexi- bility		-		-		+	+	+		+
Integrity		-			-				-		-
Inter-oper-ability		-	+	-			+
Maintai-nabilit	+	-	+					+			+
Port-ability		-	+		+	-			+		+
Reli- ability	+	-	+			+				+	+
Reus-ability		-	+	-				-			+
Robust-ness	+	-						+
Test-ability	+	-	+			+		+

While the '+' sign indicates positive impact, the '-' sign indicates negative impact. This is only an likely indication of the dependencies and in reality, this could be different. The important takeaway however is that there is a need for planning and prioritizing the quality attributes for every software being designed or built and the prioritization has to be accomplished keeping mind the inter-dependencies amongst the quality attributes. This would mean that there should be some trade-off made and the business and IT should be in agreement with these trade off decisions.

SEI's Architecture Trade-off Analysis Method (ATAM) provides a structured method to evaluate the trade off points. . The ATAM not only reveals how well an architecture satisfies particular quality goals (such as performance or modifiability), but it also provides insight into how those quality attributes interact with each other—how they trade off against each other. Such design decisions are critical; they have the most far-reaching consequences and are the most difficult to change after a system has been implemented.

A prerequisite of an evaluation is to have a statement of quality attribute requirements and a specification of the architecture with a clear articulation of the architectural design decisions. However, it is not uncommon for quality attribute requirement specifications and architecture renderings to be vague and ambiguous. Therefore, two of the major goals of ATAM are to

• elicit and refine a precise statement of the architecture’s driving quality attribute requirements 
• elicit and refine a precise statement of the architectural design decisions

Sensitivity points use the language of the attribute characterizations. So, when performing an ATAM, the attribute characterizations are used as a vehicle for suggesting questions and analyses that guide  towards potential sensitivity points. For example, the priority of a specific quality attribute might be a sensitivity point if it is a key property for achieving an important latency goal (a response) of the system. It is not uncommon for an architect to answer an elicitation question by saying: “we haven’t made that decision yet”. However, it is important to flag key decisions that have been made as well as key decisions that have not yet been made.

All sensitivity points and tradeoff points are candidate risks. By the end of the ATAM, all sensitivity points and tradeoff points should be categorized as either a risk or a non-risk. The risks/non-risks, sensitivity points, and tradeoffs are gathered together in three separate lists.