Governance

The Rise and Rise of BYOD

by
Amazon Kindle V Apple iPad
As the festive and gift season approaches, our favourite consumer technology vendors are gearing up to release a range of new gadgets and consumer devices such as laptops, smartphones and tablets. Apple’s iPad, iPhone and iPod for instance have dominated many a wish lists and gift lists for the past years. And Apple competitors are not far behind with Google, Samsung and lately Amazon with Kindle trying to steal the market share from Apple in this lucrative and ever-increasing consumer technology segment. This year in particular the tablet segment is abuzz with not one not two but three high-profile product launches just weeks ahead of the festive season. Apple iPad mini, Amazon’s new Kindle and the eagerly anticipated Microsoft tablet, all are slated to make blockbuster debut and coming after our share of gift season wallet. 
Apple iPhone V Samsung S3
And many of us, technology geeks or not are eagerly awaiting release and availability of such devices along with new smartphone models from Samsung’s new small S3 and Apple’s new big iPhone 5. But not everyone is happy with this onslaught of new consumer technology devices. And its not just the print media who is worried about losing yet another batch of potential traditional readers to these new breed of ebook and emagazine readers. A couple of my CIO and CTO friends who look after a large number of IT users for instance, are not particularly happy at these developments and the new flood of such devices. Why? The answer is simple….the rise and rise of the phenomenon called BYOD!
The rise of bring your own device (BYOD) programs is the single most radical shift in the economics of client computing for business since PCs invaded the workplace, according to Gartner. So really what is BYOD? Gartner defines BYOD as an alternative strategy that allows employees, business partners and other users to use personally selected and purchased client devices to execute enterprise applications and access data. For most organizations, the program is currently limited to smartphones and tablets, but the strategy may also be used for PCs and may include subsidies for equipment or service fees.
A recent survey of 578 senior-level executives commissioned by Cisco found that despite concerns from corporate officials, companies increasingly are allowing, in varying degrees, employees to use their own mobile devices – in particular, smartphones and tablets – in the workplace, and to access the corporate network and data. “Overall, the results found that although many executives are uneasy about the security of corporate information on mobile devices, the trend is largely unstoppable and proper policies must be initiated to underpin access to this sensitive information,” Chuck Robbins, Cisco’s newly promoted senior vice president of worldwide sales, wrote in an 10 October post on Cisco’s blog.
Tablets are fast becoming media consumers
The rise of smartphones and, more recently, tablets – fueled by Apple’s wildly popular iPad – have been the key drivers in the BYOD trend, where rather than accepting company-issued technology, workers have pushed to use their own devices for work. Cisco and a host of other vendors have for more than a year been rolling out solutions designed to make it easier for businesses to identify and manage employee-owned devices on the network, and to secure the companies’ information.  
According to the Cisco survey, conducted last month by Economist Intelligence Unit, most executives are uneasy about their companies’ mobile data-access policies, and while 42 percent said that C-level executives need secure and timely access to strategic data, only 28 percent said it’s appropriate to access this information from mobile devices. Forty-nine percent said that the complexity of securing so many different devices and a lack of knowledge about the security and risks involved with mobile access are top challenges for their firms.
This trend is set to grow exponentially next year – whether businesses actively manage it or not, according to a latest industry report published in IT Business Canada. Two-thirds of businesses already are seen some form of BYOD phenomenon in their office, but just one in four have actively created a policy that allows for consumer devices to be used in the workplace. The report quotes the findings of an Info-Tech Indaba survey sponsored by Telus Corp. This could cause problems raising security issues and complicating IT environments with multiple devices and operating systems. For 2013, the most popular technology for BYOD efforts is smartphones with 72 per cent of firms expressing at least some interest, according to Info-Tech. The next most popular is tablets with 64 per cent of businesses expressing interest, and then laptops with 59 per cent showing interest. 
As a recent CIO article has articulated, the best practice seems to be to centralize the purchase and deployment of tablets and smartphones. In addition to simplifying device management, this strategy gave the companies more leverage with their preferred carriers. When individual employees paid their monthly phone bills and submitted them on expense reports, the companies had no clout to negotiate with. When all the monthly bills were rolled into one, they got lower rates. As Gartner suggests IT’s best strategy to deal with the rise of BYOD is to address it with a combination of policy, software, infrastructure controls and education in the near term; and with application management and appropriate cloud services in the longer term. Policies must be built in conjunction with legal and HR departments for the tax, labor, corporate liability and employee privacy implications.

The Open Group SOA Governance Framework Becomes an International Standard

by

The Open Group SOA Governance Framework is now an International Standard, having passed its six month ratification vote in ISO and IEC. According to Gartner, effective governance is a key success factor for Service-Oriented Architecture (SOA) solutions today and in the future. Continue reading →

Podcast on the Enterprise Architecture profession–Interview with CIPS’s Stephen Ibaraki

by

Way back in April, I announced the first of two podcasts with the Canadian Information Processing Society.  I just realized this weekend that I had not announced the availability of the second of those podcasts.  Error corrected.

The second podcast, once again hosted by the inimitable Stephen Ibaraki, focuses much more on the growth and progress of the Enterprise Architecture profession itself.  Specifically this podcast reflects upon:

  • The role of Business Architecture in Enterprise Architecture?
  • Does an Enterprise Architect have to be able to discuss technical issues like cloud computing?
  • How would you define Enterprise Architecture?
  • The value proposition of the Enterprise Architect?

 

For full details, and a link to the podcast, visit the Canadian IT Manager’s Connection, a TechNet site. 

Sequestration Planning May Illuminate Value Engineering via Enterprise Architecture

by

 The next 5 months portend a spectacle of US Congressional battles to be waged ahead of the pending, mandatory “sequester” – automatic, mandatory federal government spending reductions of about $1 Trillion over 9 years, in non-exempt, discretionary appropriations, set to take effect 1/2/2013. Forward-thinking planners in government IT organizations, in large Programs that depend upon IT, and among the Systems Integration (SI) community are likely to dust off Enterprise Architecture skills for analyzing budget cut implications across their IT investment portfolios, and possible cost savings opportunities to offset them. Leveraging a methodical, EA-guided approach to both assess impacts and adjust spending priorities, while illuminating new areas of savings, is a sure route to mitigating serious risks and delays to delivery of critical citizen services.

Whether you’re dusting off the existing EA artifacts, or need to take a very rapid, optimized route to constructing initial enterprise IT models, the driving principle at this time will be rapid, absolute reduction in complexity with a clear line-of-sight to cost savings. “Complexity” here simply refers to an inefficient or needlessly detailed volume of time and resources applied to deliver IT solutions – time spent re-engineering processes, building redundant interfaces and monitors, installing hardware & software in a piecemeal fashion.

Driving complexity, and therefore introducing cost savings, out of engineered systems is the central tenet of “Value Engineering”  – “the optimization of a system’s outputs by crafting a mix of performance (function) and costs”. Essentially, deliver the same capabilities with better value by driving down the cost to build and/or operate. Section 52.248-1 of the FAR (Federal Acquisition Regulations) describes the “Value Engineering Clause” that is inserted into many large Federal IT contracts – enabling the contractor to propose changes to the system being developed (i.e. a “Value Engineering Change Proposal”, or VECP). If the proposal is accepted, the actual or collateral savings derived by the government (through cost modification to the contract) can be shared with the contractor. It’s a win-win opportunity for the government, system beneficiaries and the contractor community to discover and propose engineering changes that will lower costs, yet still deliver the same or better results.

Many VECPs are submitted for technology assets – i.e. contained systems that may work better when newer, less-costly components are substituted…like missile systems or electronic devices. This may be because the contractor typically is the sole source of knowledge and research concerning how to optimize and build the components, the “value” and function of the asset is very clear (i.e. it’s delivered and explodes on target) and constant innovation is a demand of the environment. VECPs are also submitted for IT systems and programs, though it’s much more difficult to identify and propose the specific cost savings or cost avoidance that might result – since IT systems are frequently dependent upon many external or interfaced elements, vendor products and processes.

An EA-centric review of a program or line-of-business IT investment may quickly yield insight that would lead to specific value engineering opportunities, and therefore reductions in IT costs. For example, a particular set of information may be created, shared and recreated across several systems, using different processes, datastores and technologies. An segmented EA approach driving down from the particular business, process and information domains, may quickly illuminate targets of opportunity for database or interface consolidation – and therefore potential consolidation of supporting technologies (i.e. storage, networking, processors). This may lead to optimized technical operations and business process performance, which can be clearly mapped back to the Enterprise Architecture to validate that governance and mission requirements are (still) met, cross-enterprise risks are mitigated, and IT investment portfolios and procurement activities are properly adjusted or re-aligned.

With this kind of information, a VECP could be constructed that very clearly proposes both program-specific and collateral (i.e. across the rest of the enterprise) savings resulting from introduction of state-of-the-art consolidating technologies (for example, pre-integrated, self-contained and consolidated database engineered systems, perhaps cloud-enabled). At the very least, an EA view can help identify and prioritize targets of opportunity for Value Engineering that may become part of an effective and timely sequestration response – both before and after such an event, and in fact as part of the annual capital planning and investment control (CPIC) processes.

Sequestration Planning May Illuminate Value Engineering via Enterprise Architecture

by

 The next 5 months portend a spectacle of US Congressional battles to be waged ahead of the pending, mandatory “sequester” – automatic, mandatory federal government spending reductions of about $1 Trillion over 9 years, in non-exempt, discretionary appropriations, set to take effect 1/2/2013. Forward-thinking planners in government IT organizations, in large Programs that depend upon IT, and among the Systems Integration (SI) community are likely to dust off Enterprise Architecture skills for analyzing budget cut implications across their IT investment portfolios, and possible cost savings opportunities to offset them. Leveraging a methodical, EA-guided approach to both assess impacts and adjust spending priorities, while illuminating new areas of savings, is a sure route to mitigating serious risks and delays to delivery of critical citizen services.

Whether you’re dusting off the existing EA artifacts, or need to take a very rapid, optimized route to constructing initial enterprise IT models, the driving principle at this time will be rapid, absolute reduction in complexity with a clear line-of-sight to cost savings. “Complexity” here simply refers to an inefficient or needlessly detailed volume of time and resources applied to deliver IT solutions – time spent re-engineering processes, building redundant interfaces and monitors, installing hardware & software in a piecemeal fashion.

Driving complexity, and therefore introducing cost savings, out of engineered systems is the central tenet of “Value Engineering”  – “the optimization of a system’s outputs by crafting a mix of performance (function) and costs”. Essentially, deliver the same capabilities with better value by driving down the cost to build and/or operate. Section 52.248-1 of the FAR (Federal Acquisition Regulations) describes the “Value Engineering Clause” that is inserted into many large Federal IT contracts – enabling the contractor to propose changes to the system being developed (i.e. a “Value Engineering Change Proposal”, or VECP). If the proposal is accepted, the actual or collateral savings derived by the government (through cost modification to the contract) can be shared with the contractor. It’s a win-win opportunity for the government, system beneficiaries and the contractor community to discover and propose engineering changes that will lower costs, yet still deliver the same or better results.

Many VECPs are submitted for technology assets – i.e. contained systems that may work better when newer, less-costly components are substituted…like missile systems or electronic devices. This may be because the contractor typically is the sole source of knowledge and research concerning how to optimize and build the components, the “value” and function of the asset is very clear (i.e. it’s delivered and explodes on target) and constant innovation is a demand of the environment. VECPs are also submitted for IT systems and programs, though it’s much more difficult to identify and propose the specific cost savings or cost avoidance that might result – since IT systems are frequently dependent upon many external or interfaced elements, vendor products and processes.

An EA-centric review of a program or line-of-business IT investment may quickly yield insight that would lead to specific value engineering opportunities, and therefore reductions in IT costs. For example, a particular set of information may be created, shared and recreated across several systems, using different processes, datastores and technologies. An segmented EA approach driving down from the particular business, process and information domains, may quickly illuminate targets of opportunity for database or interface consolidation – and therefore potential consolidation of supporting technologies (i.e. storage, networking, processors). This may lead to optimized technical operations and business process performance, which can be clearly mapped back to the Enterprise Architecture to validate that governance and mission requirements are (still) met, cross-enterprise risks are mitigated, and IT investment portfolios and procurement activities are properly adjusted or re-aligned.

With this kind of information, a VECP could be constructed that very clearly proposes both program-specific and collateral (i.e. across the rest of the enterprise) savings resulting from introduction of state-of-the-art consolidating technologies (for example, pre-integrated, self-contained and consolidated database engineered systems, perhaps cloud-enabled). At the very least, an EA view can help identify and prioritize targets of opportunity for Value Engineering that may become part of an effective and timely sequestration response – both before and after such an event, and in fact as part of the annual capital planning and investment control (CPIC) processes.

Using Cobit 5 Part 3 – The Policy Hierarchy

by

Many companies do not do governance well. A primary reason for this is a focus on governance “process” at the expense of policies. And, where policies are established, it is common to observe a surfeit of bad, inconsistent policies that are overlapping and generally ignored. As a result much governance is carried out by opinion; and governance decisions are not easily repeatable.

The Cobit 5 framework provides reference models for process and goals but, other than providing very general guidance, stops short of any detail at all relating to principles and policy. However in fairness Cobit 5 does recommend “a (hierarchical) structure into which all policies should fit and clearly make the link to the underlying principles”.

So what does a policy hierarchy look like? Does each organization need to invent its own unique structure and content?  Actually we need more than just a policy hierarchy, we need a model that helps us establish a consistent approach to policy search and description. And whilst every organization will have unique needs, much of the hierarchy and policy content will be reusable. What will usually be highly customized are the contexts and their relationships with policy assertions.
 
In the diagram:
– policy type – classifies the policy. It can be hierarchic.
– policy subject – identifies the focus of the policy the class of object being governed.
– policy – a strategy or directive defined independently from how it is carried out
– policy assertion  – is an atomic policy requirement, expressed as a statement that must be true or false
– policy context  – an entity that limits the reach of a Policy.
– policy effect – an intended and/or an actual outcome of a Business Policy. This can be the Principle(s), Goal(s) or Outcome(s), which of course map neatly to Cobit 5.
Let’s look at an example:

Meta Class  Example
Policy Type Architecture        
Policy Subject Application Architecture
Policy Interfacing
Policy Assertion All new Application Interfaces must be loose coupled.
Policy Context Global applicability
Policy Effect Principle: Interoperable; IT Goal: Agility

Now to put this more broadly into the Cobit 5 context, here’s a fragment of a policy hierarchy, mapped to Policy Subect and Cobit 5 IT Goals.

The policy hierarchy shown above is not rocket science. However it facilitates consistency and communication to all the various stakeholders. You could at a stretch manage policies in a spreadsheet, but in practice it would be advisable to use something like Sharepoint or an equivalent, that allows you to manage the life cycle, status and so on. In a further elaborations of this little series of blog posts I will explore policy relationships with guidance and standards, policy assertion and context development plus the broader policy management model.

Reference: 
Using Cobit 5 – Part 1: Principles
Using Cobit 5 – Part 2: Policy Nomenclature

Next Step: Talk to David about how to apply effective, policy based governance.  

Move to Cloud Need Not Be Sensational

by

As the cloud computing adaption and maturity accelerates, a number of case studies of early cloud migration are emerging. Ironically most of such case studies often talk about success of such migration and dynamic business and technology benefits it de…

Move to Cloud Need Not Be Sensational

by

As the cloud computing adaption and maturity accelerates, a number of case studies of early cloud migration are emerging. Ironically most of such case studies often talk about success of such migration and dynamic business and technology benefits it de…

Using Cobit 5 – Part 2: Policy Nomenclature

by

As discussed in Part 1, for me the primary value in Cobit 5 is the formalization of policy as a concept that has a life cycle and management process. In CBDI-SAE we have focused very strongly on defining the policy hierarchy and instances as the mechanism by which consistency is delivered and governed. Consequently over the years I have been critical of Cobit 4.1 because it was essentially promoting process based governance – if you are executing this process, with some nodding in the direction of general outcomes, then everything’s OK.

So I am very pleased to see policy introduced in a more coherent manner in Cobit 5. The 4.1 definition of policy was: “Generally, a document that records a high-level principle or course of action that has been decided upon. A policy’s intended purpose is to influence and guide both present and future decision making to be in line with the philosophy, objectives and strategic plans established by the enterprise’s management teams.”

In Cobit 5 the definition changes to: “Overall intention and direction as formally expressed by management.” This is better, but still not quite there. Contrast it with the CBDI-SAE definition: “A strategy or directive defined independently from how it is carried out.” I could ask what does management mean? If it was really necessary to include, then a reference to Governance Board, Design Authority or equivalent might have been helpful.

However, minor irritations aside, what Cobit 5 does is lay down a clear requirement for policy “to be part of an overall governance and management framework providing a (hierarchical) structure into which all policies should fit and clearly make the link to the underlying principles”. Further Cobit 5 separates Policy from Principle – a very important step. Also very sensibly Cobit 5 does not attempt to define policy instances, nor indeed the hierarchy and this allows specialists (such as ourselves) to map and or align our pre-existing hierarchy to the Cobit framework. I will return to and expand upon the hierarchy in the next part of this series. But first I want to consider policy nomenclature and structure in a little more depth.

Cobit 5 says “Policies provide more detailed guidance on how to put principles into practice . . .” This is potentially misleading. Yes policies are practical strategies and directives that support and realize principles, but to suggest they must be detailed is incorrect. Good policies should be formed as assertions that are true or false and should not be detailed with “how” they are achieved. The best policies are those that are mandatory – providing unequivocal direction to architects and service delivery teams. The detail is best left to Guidelines – or recommendations that indicate use of patterns and practices.

This simple error in Cobit 5 is actually a fundamental flaw that I would like to see fixed. Time and time again I come across confusion over the nomenclature being used by our clients to support governance. Confusion in this area leads to poor  implementation and inconsistent governance. The terms policy, standard and guideline are very commonly used, but frequently mean very different things.

In this context, the good news is Cobit 5 has at least defined policy as the overall intention and direction. I will certainly be using this to advise my clients to standardize on this terminology. Guidelines should then be regarded as practice recommendations. These are not policies with a lower level of mandatory status. At some stage they may evolve to become policies, but not necessarily.

Standards are perhaps a little easier. The CBDI-SAE definition is “A collection of rules or practices which are relevant in Service Architecture or Engineering.” And for good measure the meta type Protocol is a subtype of Standard. Standards therefore are clearly defining the mandatory requirement to comply with specific protocols and practices in given contexts.

To summarize, Cobit 5 is a major step forward. It encourages a policy framework and nomenclature standardization on “policy” for the major directives and strategy assertions and doesn’t preclude complementary Guidelines and Standards under a common management process. In addition Cobit 5 provides the outline framework for development of a policy hierarchy and policy instances, which I will cover in some detail in the next part of this series of blogs.

References: Using Cobit 5 – Part 1 – Principles
                   Using Cobit 5 – Part 3 – The Policy Hierarchy