<code><span style="color:blue; font-size:8pt; background-color:#f4f4f4">public<span style="color:black">
						<span style="color:blue">override<span style="color:black">
								<span style="color:blue">void<span style="color:black"> FeatureUpgrading(SPFeatureReceiverProperties properties, <span style="color:blue">string<span style="color:black"> upgradeActionName, System.Collections.Generic.IDictionary<<span style="color:blue">string<span style="color:black">, <span style="color:blue">string<span style="color:black">> parameters)
</span></span></span></span></span></span></span></span></span></span></span></span></code>

<code><span style="color:black; font-size:8pt">{
</span></code>

<code><span style="color:black; font-size:8pt; background-color:#f4f4f4">    SPWeb parentWeb = (SPWeb)properties.Feature.Parent;
</span></code>

<code><span style="color:black; font-size:8pt; background-color:#f4f4f4">
					<span style="color:blue">switch<span style="color:black"> (upgradeActionName)
</span></span></span></code>

<code><span style="color:black; font-size:8pt">    {
</span></code>

<code><span style="color:black; font-size:8pt; background-color:#f4f4f4">
					<span style="color:blue">case<span style="color:black">
							<span style="color:#006080">"UpdateSomething"<span style="color:black">:
</span></span></span></span></span></code>

<code><span style="color:black; font-size:8pt">
					<span style="color:blue">string<span style="color:black"> someValue = parameters[<span style="color:#006080">"PassSomeValue"<span style="color:black">];
</span></span></span></span></span></code>

<code><span style="color:black; font-size:8pt; background-color:#f4f4f4">
					<span style="color:green">// do some stuff.. <span style="color:black">
						</span></span></span></code>

<code><span style="color:black; font-size:8pt">
					<span style="color:blue">break<span style="color:black">;
</span></span></span></code>

<code><span style="color:black; font-size:8pt; background-color:#f4f4f4">
					<span style="color:blue">default<span style="color:black">:
</span></span></span></code>

<code><span style="color:black; font-size:8pt">
					<span style="color:blue">break<span style="color:black">;
</span></span></span></code>

<code><span style="color:black; font-size:8pt; background-color:#f4f4f4">    }
</span></code>

<code><span style="color:black; font-size:8pt">}
</span></code>

The standard for managing the feature upgrade process will be to use the Open Source SharePoint Feature Upgrade kit available at http://spfeatureupgrade.codeplex.com/. This extends Central Administration to provide this functionality as well as includes PowerShell cmdlets to facilitate the process. More explanation is provided here: http://www.sharepointnutsandbolts.com/search?q=cmdlet

1. Feature Activation
   

Do not instantiate an SPWeb, SPSite, SPList, or SPListItem object within an event receiver. Event receivers that instantiate these objects instead of using the instances passed via the event properties can cause the following issues:

• Significant additional roundtrips to the database (one write operation can result in up to five additional roundtrips in each event receiver).
• Calls to the Update method on these instances can cause subsequent Update calls in other registered event receivers to fail.

1. Code Design
   

This section is not intended to be a comprehensive listing of TGT’s software development best practices but rather an outline of SharePoint specific code design standards related to the SharePoint ALM

To provide more flexibility for your code, you should not place your upgrade code directly inside the FeatureUpgrading event receiver. Instead, put the code in some centralized location and refer to it inside the event receiver

By placing your upgrade code inside a centralized utility class, you increase both the reusability and the testability of your code, because you can perform the same actions in multiple locations. You should also try to design your custom upgrade actions as generically as possible, using parameters to make them applicable to specific upgrade scenarios. (Juvonen, 2011)

1. Upgrade Process Standards
   

When a feature has previously been deployed to a non-development environment (SIT, QA, PROD) it must be versioned and upgraded appropriately. The following steps must be followed.

1. Upgrade the version number of the feature per the standards outlined in section 6.2 of this document.
2. Make the appropriate changes to the Feature.xml file to deal with any relevant upgrade actions that must occur to move to the next version.
3. If the feature has the potential to be used in multiple places ensure that scenarios for a new activation as well as an upgrade are handled. This is accomplished by writing any appropriate code in the FeatureUpgrading and FeatureActivating event handlers
4. Package the WSP
5. Communicate to the infrastructure team that this is an Upgrade in order to ensure required changes are pushed down to existing instances of the feature if required.

1. Bibliography
   

   Juvonen, V. (2011, February). Application Lifecycle Management in SharePoint 2010. Retrieved from MSDN: http://msdn.microsoft.com/en-us/library/gg604045.aspx

   O’Brien, C. (2011). Real World SharePoint 2010. Indianapolis, Indiana: Wiley Publishing.

   O’Brien, C. (n.d.). Feature Upgrade Fundamentals. Retrieved from Fun and Games with the Nuts and Bolts of SharePoint: http://www.sharepointnutsandbolts.com/2010/06/feature-upgrade-part-1-fundamentals.html

If I have one passion in this world it’s kids. Well, libertarian philosophy and Austrian Economics are right up there of course but at the end of the day its kids. I suppose the desire to help kids comes from my upbringing as well as some of the events that have transpired during my adult life. I grew up in a home where my mom was always there and my dad was exactly the kind of father 2 boys needed. My parents took in foster kids and while as a child I probably didn’t appreciate the importance of that gesture I certainly do now. My parents have always been the type to help others whether it was bringing a child over from Belarus who had been exposed to radiation from Chernobyl and pretty much feeding their village for 10 years to volunteering at the Food Bank.

I was a Big Brother for a period of time in the mid 90′s which was a rewarding experience however I’m certain I would be far better at it now. My young daughters having gone through the death of their mother and learning to love and think of another woman as their mom has really clarified the importance of parents and a safe and stable home – although stable can be a relative term I guess. That’s enough history for now and on to my idea:

I’m an IT geek who lives in London, Ontario, and was thinking what a valuable experience it would be for underprivileged kids to be able to attend, at no cost, a computer camp for a week or so. The objectives as I see them would be as follows:

• To have the kids go through an interview process to attend the camp
• To require a dress code while attending the camp – hopefully some local businesses would donate to those that needed help in this area
• To teach the kids some software development fundamentals
• I don’t really want the camp to be about software but I want learning how to program to be the mechanism to achieve:
  • To meet new kids
  • To learn to present in front of others
  • To show them that professional dudes are people like everyone else
  • To understand how business works
  • To appreciate that they can truly make a difference

I’d need to organize the following logistics from what I can see:

1. Finding a place that would do it for free
2. Computers
3. People to help teach
4. Develop the curriculum
5. Food?
6. I’m sure there are a million other things

Clearly this is a very preliminary idea at this point so I thought I would try to leverage the power of Crowdsourcing to help me crystallize this into a truly meaningful experience for some kids that could really use a meaningful experience.

Sincerely,

Jason MacKenzie

Executive Summary

The purpose of this document is to describe my view of developing and implementing SharePoint governance. A strong SharePoint governance practice is an important component in using this software platform to deliver real business value. SharePoint governance is also frequently overlooked or poorly implemented resulting in increased risk, complexity and cost while diminishing the benefits to the organization. This document discusses key concepts related to governance but is not in and of itself a governance plan. Governance requirements vary from organization to organization and should be created with a full understanding of the goals, organizational culture, staffing and technology infrastructure of our customers.

SharePoint governance is critical because SharePoint is a business solution supported by IT. The intention of SharePoint, along with any enterprise platform, is for it to be leveraged to allow the organization to more effectively meet business goals. SharePoint governance will help define ownership, roles and responsibilities along with policies and procedures that will create a much better environment for success.

Governance is a broad topic that is divided into numerous categories. The term “governance” refers to the process of decision making and the process by which decisions are implemented. We recognize the critical importance of an integrated corporate governance framework and that SharePoint governance is a subset of that larger initiative. This document will also discusses subjects such as Enterprise Architecture that are not commonly associated with SharePoint governance. We will make the case that these disciplines can enhance the effectiveness of your SharePoint implementation.

SharePoint 2010 is an enterprise collaboration platform that provides the following capabilities: Sites, Communities, Insights, Search, Content and Composites. This diverse array of capabilities provides a wide-spectrum of features that can help organizations realize their strategic business objectives. There is also significant downside risk that mitigated by a well-conceived and executed governance strategy. SharePoint governance can be thought of in the following contexts:

• IT Assurance
  
• Project Governance
  
• Information Governance
  
• Technology & Business Alignment
  
• Continuous Improvement
  

It is also a beneficial to engage in the creation of a business model for SharePoint prior to moving forward with the implementation. At a generic level a business model describes the rationale of how an organization creates, delivers, and captures value. Your organizations business model is an excellent starting point to map the goals and objectives of your SharePoint implementation to the goals and objectives of the organization.

It is my position that governance, supported by enterprise architecture and the creation and maintenance of a business model(s) will result in more effective decisions being made more quickly allowing your business to respond more quickly to changing market conditions thereby generating more value for your customers, employees and shareholders.

1. Integrated Governance Framework

Governance is a broad term that applies at many different levels of an organization. Corporate governance refers to the set of processes, customs, policies, laws, and institutions affecting the way a corporation (or company) is directed, administered or controlled. An integrated corporate governance framework should consist of capital planning, workforce planning, security, program management and enterprise architecture. This framework should provide the processes and resources to ensure that corporate activities are aligned with achieving the objectives of the corporation.

Information Technology Governance, IT Governance is a subset discipline of Corporate Governance focused on information technology (IT) systems and their performance and risk management. The primary goals of IT Governance are to assure that the investments in IT generate business value, and to mitigate the risks that are associated with IT. IT Governance is not separate from Corporate Governance but rather a complimentary practice that focuses on how Information Technology assets deliver value within the context of the overall Corporate Governance model

Service Governance is the set of processes, procedures, policies and guidelines and tools affecting the way people direct administer or use a specific IT service within an organization. IT Service Governance defines the relationship among how the many players involved with an IT service work together and how the collectively support the vision/goals originally defined for that service.

The goal of discussing the various forms of governance is intended to demonstrate that SharePoint governance cannot be effective in the absence of a broader strategic context. If a corporate governance model has not been created, attempting to implement a SharePoint specific model will be problematic.

Figure 1 – Governance Hierarchy

The following points illustrate some fundamental considerations when devising a governance strategy. Governance activities must be measured for both their effect on business performance and overall compliance. If these activities cannot be measured they should not be governed. If an organization is not willing or able to enforce the policies, processes and expectations required to comply with the governance strategy then they should not be governed. If the activities do not ultimately result in a net benefit to the profitability of the organization they should not be governed and in fact, not carried out at all.

1. Business Modeling

As previously mentioned a business model refers to the rationale of how an organization creates, delivers, and captures value. A business model can be broken down into blocks that show how a company intends to make money. It is an excellent tool for blueprinting strategy and understanding the potential impact of change.

The blocks that define the business model are: Key Partners, Key Activities, Key Resources, Value Propositions, Customer Relationships, Channels, Customer Segments, Cost Structure and Revenue Streams. These blocks cover the 4 main areas of business: customers, offer, infrastructure and financial viability. (Generation).

It is an important exercise to create a business model for your SharePoint implementation in order to understand how the 9 segments work together to create business value. An excellent business model canvas is available at http://www.businessmodelgeneration.com. An example follows on how to use a business model to visualize the impact of changes. I have significant experience in generating effective and accurate business models.

Scenario

A manufacturing organization has decided to implement SharePoint to achieve the following 3 objectives: Increase collaboration, improve the accuracy of enterprise search, and centralize their IT infrastructure in a Shared Services Model. Let us quickly break down how the 9 building blocks could be populated in this scenario.

The following year the executive, in the quest to increase the level of communication with suppliers, demands that specific information on the portal be made available via an extranet. The business model provides insight into the impact of this change from the perspective of the 9 building blocks. The building blocks are related and changes to one will affect many.

In this scenario, a customer group, Executives has instructed that SharePoint will support a new category of customer, the supplier. This directive adds a new element to our value proposition which is the availability of accurate information for suppliers. This will open a new channel, the supplier portal that we use to interact with our customers. The organization must then ask itself if it has the appropriate staffing in place to support the new customer segment as well as the infrastructure to handle the increased user base extranet availability. This could impact the cost structure associated with the SharePoint business model.

Using the business model canvas will provide an organization to clearly see what the potential impacts of a change to that model are. This process also helps ensure the model is aligned with the overall business model of the organization. It also helps people understand what SharePoint should be used for any why. Different models should be prototyped to help understand how SharePoint can be used the most effectively in an organization. A significant change to one building block can necessitate the creation of a new business model

1. Enterprise Architecture

   1. EA Overview

Enterprise architecture describes the documentation and analysis of an organization’s current and future states from strategy, business and technology perspectives.   By defining the elements and their relationships that comprise an organization, an organizational ontology, such as strategic objective, organizational unit, business process, application etc. in the form of a metamodel you are able to quickly and accurately analyze gaps between the current and future states, model multiple future scenarios, identify duplicate data, issues of standards non-compliance and more. Enterprise architecture makes the information about an organization actionable and therefore a vital tool for achieving strategic objectives.

Enterprise Architecture is a key component of the integrated governance framework and should be run as a separate program. Enterprise Architecture, while having a significant IT component, should not be owned by the IT organization. Enterprise Architecture plays an informational role in the sense that the impact of change through all levels of the organization can be modeled and assessed. Quickly assessing potentially duplicated information, business processes etc. and developing a transition plan to a future state allows the governing bodies to make timely and accurate decisions on how to move forward.

There are numerous EA frameworks and methodologies in use. These include EA3, TOGAF, DODAF, FEAF and many more. The term framework in the EA framework typically defines what to model (the meta-model) while methodology refers the phases and activities required to gather the required information.

1. Meta-Models

EA Frameworks typically provide a meta-model (MM) that organizations can use to model their enterprises. An MM is ontology, which is a description of things and their relationships to one another. In practice, populating the content of your MM is how you define your enterprise from the strategy, business and technology perspectives.

Figure X demonstrates a simple example of an MM that demonstrates the relationship between Strategy, Initiative and Business Unit. The MM provides a single definition for each term and defines the relationship between them. A complete MM extends this paradigm to the information and technology layers as well.

Figure 2 – Metamodel Sample

(Mallik, 2011)

Once the MM is populated, various viewpoints can be generated for consumption by the appropriate stakeholders. A C-level executive may be interested in what initiatives are underway to support a specific strategic goal whereas a business unit head might be interested in understanding which business processes his/her unit is responsible for. IT personnel would be interested in knowing what application services support various business processes. These viewpoints are typically published in a tabular format to a web page for easy consumption.

Most modern EA tooling provides an API to populate models from an organization’s system of record using ETL processes. This reduces duplication and the opportunity for errors and allows for the automated population of all or some of the MM. Gartner’s 2010 Assessment of EA tools can be found here.

1. EA & SharePoint

A mature EA capability will provide an enterprise a robust way to analyze the current and future states of an enterprise. This capability is critical to ensuring the leveraging of software platforms, such as SharePoint, to delivering business value. Some examples follow to illustrate the benefit:

Information Architecture – a mature Enterprise Architecture will have all the information elements, the hierarchy, their definitions, the source of record, business processes they are associated with on so forth. Should a request come in to automate a specific process in SharePoint the Enterprise Architecture team can quickly assess the state of that process and its related entities in the organization. Should the process already exist a determination can be made to either maintain the current state and end the new initiative or move the process into SharePoint by developing a transition plan to move to the future state.

Business Architecture – enterprise architecture provides the mechanism for directly, or indirectly, linking the business-centric components of an organization to the supporting software platforms. Many an organization implementing SharePoint have difficulty demonstrating how the feature set and usage directly contribute to the company’s bottom line. Through the meta-model, EA can link strategy to specific initiatives designed to execute that strategy to business processes to the software platform that automates those processes.

Business Processes – if an upgrade to the next version of SharePoint is planned, the organization will likely want a clear picture of the risk involved. A report on all the business processes currently hosted in SharePoint may be requested to understand the potential risk on the company’s operations. EA provides the ability to quickly determine this along with the related technical infrastructure, the business units that own the process and the project and programs that will be affected.

As these examples illustrate, Enterprise Architecture and by extension, a mature governance framework will provide a mechanism for making sound strategy, business and technology decisions.

1. SharePoint Governance

This document until this point has been focused on providing the context in which SharePoint governance should function. The ultimate goal of SharePoint governance is to ensure the service meets the business needs of the customers in a secure, manageable, and cost-effective way. Governance is an ongoing process that continually evaluates new requests for the services and balances them against the business needs while strategically looking at the corporation’s longer term objectives. We will now explore the specifics of SharePoint governance including what it is, why you need it and who should be involved.

SharePoint governance can be thought of as covering the following 5 major areas.

• IT Assurance
  
  • Disaster recovery, technical infrastructure, operations and SLAs
• Project Governance
  
  • Project management, requirements management. Stakeholder management
• Information Governance
  
  • focusing on information architecture (security model, taxonomy, navigation, content types, configuration) and information management (compliance, accountability, quality, discoverability, life cycle management)
• Technology & Business Alignment
  
  • focusing on adoption, training, application usage, branding, service request process, and strategy
• Continuous Improvement
  
  • focusing on return on investment, qualitative and quantitative measurement of defined success goals, and user feedback

(Clay, 2011)

The approval and acceptance of a governance plan is an important deliverable. In order to begin the process of creating the plan the following areas should be considered.

• Current State Analysis – what are the current requirements and challenges that the service should address?
  
• Vision & Objectives for the Service – what features and capabilities will be provided to the organization?
  
• OOTB SharePoint Capabilities – what are the standard features and capabilities offered by SharePoint in relation to the vision and objectives?
  

Performing this analysis will act as the inputs to the process of determining what needs to be governed. This may include, but are not limited to:

• Service Level Agreements
• Security
• Cost/Revenue model
• Quotas
• Training
• Change Management
• Migration Planning

Determining the most important aspects of the service to govern will then enable concrete actions to be taken to implement the governance model. These actions may include:

• Configuring SharePoint to comply with the governance requirements
• Identifying any supporting utilities and 3^rd party tools that are required
• Development of a training and communication plan
• Creation of related policies and procedures.

There are many more potential areas to be governed. It’s important to identify the minimum level of governance initially required. This will allow it to be more quickly implemented and understood as the maturity of the service evolves the governance will evolve in tandem.

Some governance processes will be manual and others can be automated through the out of the box feature set of SharePoint 2010. Some of the OOTB features and their relation to the 3 of the 5 major governance areas are listed below. These features, when used can help manage the IT Services being delivered as well as the proper governance of the corporate information stored in SharePoint.

• IT Assurance
  
  • Quotas, Features, SharePoint Designer configuration, Sandbox Solutions, Backup & Recovery, Content Storage
• Information Governance
  
  • Site locks, Document Management, Content Approval, Versioning, Records management
• Technology & Business Alignment
  • Site Templates, SharePoint Designer configuration

1. SharePoint Governance Teams

Successful SharePoint governance relies on having the appropriate resources, from various levels of the organizations, focused on the developing and operating the governance directives. These resources should be divided in teams focused on both strategic and tactical activities.

The various roles that comprise SharePoint governance teams may include:

• Executive stakeholders
• Business users and power users who are supportive of SharePoint.
• Systems analysts who are devoted to supporting SharePoint.
• Developers who create custom functionality.
• Systems administrators who manage the SharePoint farms.
• Technical leadership who understand how to translate business requests into SharePoint solutions.

The Strategy team should be comprised of business and technology leaders, financial leaders, information workers as well as security and compliance officers as appropriate. This team’s mission is to ensure that business objectives for SharePoint are being measured and met. They will also provide direction to the various tactical teams in order to ensure the activities being undertaken are appropriate.

Many organizations have an IT Steering Committee (ITSC) that performs a similar function in ensuring that technology investments are aligned with the business’ objectives. The ITSC accomplishes this by establishing executive leadership in the development of standards, policies, and the prioritization of various initiatives. The SharePoint strategy team may be comprised of some of the same members and will perform a similar role albeit focused on the SharePoint platform. Ideally these teams will be separate with clearly defined processes detailing the interaction between them.

The tactical teams focus on the actual implementation and operation of the SharePoint platform. These teams can include Operations, Development and Support. The Operations team is responsible for ensuring the platform is running and meeting SLAs, crafting a disaster recovery strategy, maintenance and monitoring plans and deployments including policies and schedules. The Development team can be comprised of a range of roles from technically adept business users to SharePoint software developers. This team is responsible for defining development standards, determining and enforcing which tools are appropriate in which circumstances and defining development and deployment related policies and procedures. The Support team is charged with user training, managing the site provisioning process and managing taxonomy, navigation and developing communication plans. The teams, their composition and their activities will be specific for your organization.

An excellent discussion of governance teams that formed the basis of this section was written by Richard Harbridge of Allin Consulting and can be found here: http://www.cmswire.com/cms/information-management/the-5-teams-you-need-for-effective-sharepoint-governance-012328.php

1. SharePoint Maturity Model

A maturity model represents a definition of the roadmap to optimally developing a specific capability. It allows an organization to quantitatively assess the current state and plan the progression to the next. A maturity model also structures that progression by clearly defining what must be achieved prior to moving to the next phase. You want to go from Phase 1 to Phase 2. Once you’re at Phase 2 you can move to Phase 3.

There are many versions of maturity models available and the challenge Is to either select or customize one that is aligned with the goals of your organization. Maturity models are typically defined along a continuum with distinct and measurable phases. The Capability Maturity Model defines the following generic levels of maturity:

1. Initial (chaotic, ad hoc, individual heroics) – the starting point for use of a new or undocumented repeat process.
2. Repeatable – the process is at least documented sufficiently such that repeating the same steps may be attempted.
3. Defined – the process is defined/confirmed as a standard business process
4. Managed – the process is quantitatively managed in accordance with agreed-upon metrics.
5. Optimizing – process management includes deliberate process optimization/improvement

The phases of maturity are often defined along the Y-axis of the model with the various capabilities defined along the X-axis. The capabilities will be determined by the business and technical objectives defined for the SharePoint platform. Major categories can used to organize the specific capabilities. A maturity model that has gained widespread praise throughout the industry has been created by Sadalit Van Buren of BurntSand consulting as can be reviewed here.

As with all governance activities, measure the maturity of the minimum suite of capabilities possible in order to be able to accurately assess that the right progression is occurring. An incomplete model will not provide you with enough information and an overly complex model will be cumbersome and unlikely to be maintained.

1. Summary

This document has explained the various considerations when implementing SharePoint governance. SharePoint governance functions optimally when included as a subset of an overall corporate integrated governance framework. This will ensure that business objectives, policies and procedures are clearly articulated and enforced and will provide a broader context in which SharePoint governance will operate.

Enterprise Architecture and Business Modeling will help inform decisions when assessing the current state and envisioning future states. EA provides the mechanism for modeling your enterprise and from strategy, business and technology perspectives and creating different viewpoints that are relevant to stakeholders throughout the organization. Business modeling provides a method to understand the impact of change from the perspective of the 9 building blocks to quickly visualize and assess the impact of requested changes.

SharePoint governance is comprised of 5 main areas of focus and requires specific teams made up of stakeholders throughout the organization to be actively engaged on an ongoing basis. The potential benefits related to business alignment, acceptable use, IT assurance and operational optimization are too significant to ignore. There are many potential risks to an ineffective governance program. Unfortunately, almost half of all implementations fail in this area resulting in increased cost and risk and an inability to derive the maximum amount of business value from this often significant investment.

For further information on this exciting topic or to discuss how Intelligence Among Us can be of assistance to you please contact me at jmackenzie@intelligenceamong.us

1. Bibliography

   Clay, A. (2011). SharePoint Governance 3.0. Retrieved from 21 Apps: http://www.21apps.com/governance/sharepoint-governance-3-0/

   Generation, B. M. (n.d.). Business Model Generation. Retrieved from Business Model Generation: http://www.businessmodelgeneration.com

   Mallik, N. (2011). Metamodel 101. Retrieved from Inside Architecture: http://blogs.msdn.com/b/nickmalik/archive/2011/05/26/metamodel-101.aspx

The Wikipedia definition of a metamodel illustrates the difficulty one can have in understanding the concept: A meta-model typically defines the language and processes from which to form a model. Huh?

The very plain English version from an Enterprise Architecture point of view is that a metamodel is a collection of all the stuff that makes up your enterprise and their relationships to one another. Basically it’s an ontology which our trusty source Wikipedia defines as: A standardized representation of knowledge as a set of concepts within a domain, and the relationships between those concepts.

As we’ve discussed, Enterprise Architecture is typically broken down into layers focusing on strategy, business and technology or business, application, data, technology depending on the framework you have chosen.

The metamodel is where the EA rubber hits the road so to speak. You populate your EA content by populating the various elements in the metamodel and the related properties which then provide you the ability to create different views of that information that are relevant to specific audiences. Let’s illustrate this with a simple example:

As you can see we have specific elements in each of layer of our EA. These layers are sometimes referred to as sub architectures. It is also critical to clearly define each of the elements so there is a shared understanding about what the terms mean. Looking at the diagram it becomes clear that our metamodel provides a structure for our content and enforces rules about which elements can be related to what. For the more technically inclined – think of the metamodel as your database schema

For example – a Business Initiative would obviously not be directly related to a Device in the Technology layer. However by navigating through the layers and elements you can see that there is an indirect relationship between the two. Having said that, this metamodel would allow us to analyze what business initiatives would be potentially impacted if there was a problem with a specific device.

As well as providing a common definition for the elements that comprise your enterprise, the metamodel and associated modelling tools also provide the ability to make a lot of the documentation that typically collects dust actionable. An example of this would be the ubiquitous Business Process diagram. You know – the one that always seems like a great idea for the business analyst to show how well they know the business and the one that doesn’t get updated as the change requests start flowing in.

Instead of using Visio or another drawing tool to create your swim lane diagrams you would open your modelling tool and create a new business process diagram and model it using BPMN. You would then link it to its related elements and voila! You now have a diagram that can be used in many more meaningful ways to the benefit of the enterprise. You can easily assess the impacts of any changes, you can quickly see where the process is used and by which groups in your enterprise and you can see which data elements are used to support the process. Therefore there is an incentive to, through your EA governance processes, to ensure that the process diagram is kept up to date.

Most EA frameworks provide a metamodel and the more advanced tooling supports the implementation. Below is an example of the TOGAF (The Open Group Architecture Framework Metamodel:

A tool such as IBM Rational System Architect supports the TOGAF metamodel by having the elements and their relationships predefined when a new TOGAF project is created. These elements are extensible in the sense that you can easily add organization specific properties to them which would be driven by the information requirements of the various stakeholders.

Another important point to note is that because the elements are related to one another you have flexibility in where you begin populating the metamodel. Again, this is driven by the requirements of the stakeholders. If your EA initiative is nascent you could begin by modelling the application and technology related elements and expanding upwards towards elements in the business architecture as your EA capability matures.

The EA artifacts you create (Swim Lane Diagrams, Node Connectivity Diagrams, Data Flow Diagrams etc.) are built from and linked to the elements in your metamodel. This makes the artifacts dynamic in the sense that they are driven by real data and you have the capability to drill-down through them to see all the related information. Multiple future states can then easily be modelled to assess the potential impacts of any changes.

In order to ensure that an organization gets the most value out of their technology investments there needs to be alignment between the technology and the business. This is a problem you hear constantly – everyone knows there needs to be alignment but very few understand practically how to do it, model it or measure it. Enterprise Architecture is one of the disciplines that will enable an organization to accomplish this. The metamodel is where you relate business and technology architectures which will allow you to make smarter, more well-informed decisions going forward.

Enterprise Architecture has the ability to make things visible that were previously hidden and this is done through choosing, extending, populating and reporting on the metamodel.

Theodore awoke with a start covered in sweat. Glancing over at the clock it read 2:46 am. He possessed an astonishing level of clarity about his life that he had never experienced before. He bolted from bed and emailed his supervisor. “You are the man and I can no longer work for the man.” Theo purchased himself a plane ticket to Tibet and then bought a Yak from Amazon. He donned the chuba that he had crafted with his own hands for just such an eventuality and headed to the airport. As he mounted his steed to begin his literal and figurative ascension things went south back home. The mission critical systems that Theo had been working on as a software developer crashed causing massive disruption to his former employer, aka The Man. You see, Theo was a software developer – a software developer who, unbeknownst to his teammates, sucked the big one.

As the emails started pouring the development team struggled mightily to determine what was happening and how to fix it. It began with not knowing where the source code for the system was and then when finding it finding multiple versions. Once that was sorted out the problem was knowing where to look and then deciphering the hacked together mess of spaghetti code in order to begin to understand the root cause. To make a long story short, 18 hours later the problem was resolved. But the real problems that had been festering for a long time had just been brutally exposed.

After receiving the tongue lashing of her life from the CEO, the CIO stalked down the hallway looking for the supervisor of the development team grabbed him by the ear and dragged him into her office. “You have 2 days to come up with a plan to ensure that this never happens again. It will encompass standards, processes, backup resources on systems and anything else you think is necessary. You’ve really let me and the entire company down. Now get out and get to work.”

Jason assembled his team of 10 developers and looked around the table. Quite frankly he was at a loss and didn’t know what to do he opened the floor to suggestions. Harvey, one of his more obstinate developers started with, “What is the point? We’ve tried to implement standards before and it never amounts to anything. We’re too busy, pulled in a million different directions. Besides, is anyone else going to buy a Yak and go to Tibet? Probably not so I don’t see much risk of this happening again! ” Nancy piped up with, “Plus we’re trying agile development and that doesn’t seem to be helping. Why throw more stuff into the mix.”

Jason closed his eyes and thought about how the whole “agile” thing had been going:

Full stop! This is where teams typically shoot themselves in the foot by thinking small. Invariably irrelevant suggestions like commenting code, naming conventions etc. get tossed out as good ideas. Clearly this will never be enforced leading the team to the conclusion that standards, while good on paper, are a waste of time. So what would I do? I’d Keep in mind that “big” means big in the context of our problem here. Not “big” like world peace or preventing pandemics.

Role Clarification

The first thing I would do is to explain clearly what the role of the software developer is in the organization and clarify how they are expected to add value. This means explaining, as often as necessary, that they bring value by developing custom business logic that solves real business problems. That means looking at things through the prism of the company’s mission and objectives. If you make car parts and the development activities don’t help make car parts better, faster cheaper or more safely there is a problem. Admittedly some of this is beyond the control of the software developer. In their direct sphere of influence this means not writing redundant code, using proven practices and frameworks etc. It never ceases to amaze me how developers are resistant to the idea of using something created by someone smarter.

If there are business analysts in the organization I would provide further clarification on the role of the business analyst versus developer. As a leader want my developers to be the absolute best technical experts in their field they can be. This means supporting and encouraging them to get to where they need to be but also shielding them from performing activities that won’t take them there. My role as the leader is to break down the natural resistance between these two groups so we can work productively. Strong business analysts working with exceptional developers can make magic happen.

Frameworks

Framework is one of the more overused words in the world of software development. In this context I mean the overall structure and approach for developing the required business solutions. This means taking a convention vs. configuration approach to developing solutions. Wikipedia defines this as “a software design paradigm which seeks to decrease the number of decisions that developers need to make, gaining simplicity, but not necessarily losing flexibility.” In other words – applications have been built for a long time and there is a best way to go about them. So do that and modify only what you need to suit your specific purpose.

To illustrate my point I’ll discuss ASP.Net MVC (Model-View-Controller) framework for developing dynamic web applications. For all the Microsoft haters out there – relax – there all kinds of great languages, environments and frameworks. Creating an ASP.Net MVC application gives you the following benefits.

1. A predefined solution structure as seen in the following screen shot which will provide immediate familiarity to all developers on your team.
   

    

2. Separation of Concerns. This basically means that stuff goes where it should. HTML and script go in the Views, business logic goes in the Controllers and the data access goes in the Models. Naturally a developer can still screw this all up but the framework provides a rich environment so the opportunities to deviate from the pattern are reduced.

    

3. Standard Naming Conventions. Controllers and their actions as well as views have standard naming conventions making it simpler to find what you are looking for

There are clearly more advantages but this illustrates the benefits of using frameworks in the context of this article.

Another example is ORM or Object Relational Mapping. This means using something like the Entity Framework for data access operations. What this provides is a mapping from your database tables to strongly typed objects which support CRUD operations, relationships etc. An entity data model will look like the following screen shot:

The relationships between your objects are defined by the primary key/foreign key relationships in your database. So in this example an Order object will have a related collection of OrderDetail objects. This entices the developer or DBA to create those relationships properly in the database as there is a direct benefit to the developer when developing solutions. It also follows a standard naming convention by naming the types created the same as the tables in your database which further simplifies things.

Design Patterns

Another simple approach is the adoption of a set of design patterns useful to your specific circumstance. Wikipedia defines design patterns as a general reusable solution to a commonly occurring problem within a given context. Or in other words: many of the problems you are trying to solve have been solved already so use that approach. There are many design patterns and not all will be applicable. Review them, pick a few that seem pertinent to the work you do and start using them. The developers that maintain your code in the future will thank you for it.

Governance

Clearly, a significant part of the problem is the absence of management frameworks such as IT Governance, Project Portfolio Management and Enterprise Architecture. These are beyond the scope of the developers to influence in our example with the incredibly short timeline. Going forward they will need to be established in order for the organization to truly get the most value from its technology investments. This will be covered more in a future post.

Conclusion

In our fictitious example we were presented with a catastrophic situation caused by a fragmented development team creating business solutions with no standards. The goal was to quickly come up with some ideas for minimizing the risk of this catastrophe reoccurring or minimizing the impact if it did. There are many more areas to be looked at but we discussed the some that can be implemented easily providing some quick steps in the right direction. Let’s summarize what we are planning.

1. By clarifying the role of the developers vis-à-vis the business analysts we will, in time, allow the developers to focus more closely on what they are paid to do. By helping them understand how they add value will also provide context for some of the other ideas we’ve discussed
2. Agreeing to adopt Frameworks such as the ASP.Net MVC will bring the team a long way in creating a sweeping set of standards far larger in scope than some of the typical suggestions. Naming conventions, separation of concerns, standardized HTML output, solution structures, database design and ORM are some of them. These are significant and can be accomplished easily making your team much more able to step in and maintain someone else’s solution.
3. Defining what kind of problems that are typically faced and adopting proven design patterns to solve them will also go a long way in creating more standardized business solutions reducing risk and easing maintenance.

On a more intangible note – people respond well to using these frameworks and patterns and being encouraged to be professional experts in their areas of practice. The development of professional, robust and maintainable solutions fosters satisfaction and team cohesion which leads to the development of more professional, robust and maintainable solutions. It becomes a self-perpetuating cycle of excellence.

So with a few relatively simple concepts we can accomplish some huge steps towards making ourselves a more professional and trusted team within the organization.

The ultimate goal is to make sure that the organization is not at risk the next time one of your team members decides that working for you is akin to some medieval form of torture and leaves at the drop of a hat. Best of luck Theodore – we’ll talk again soon!