Category: erwin Expert Blog

The Center of Excellence (CoE) is a broad set of activities, delivered alongside tooling to embed the use of software tools to support the Governance of future IT project design. The CoE helps achieve a business as usual status use of enterprise architecture and innovation management models.

To achieve this goal, a series of activities must take place to allow the transition from a set of reactive data capture activities to a proactive use of the tool in Governing future IT development and being a trusted component of the delivery lifecycle. The following section outlines the activities, responsibilities and skills required to make the Center of Excellence a reality.

Creating a Center of Excellence (CoE)

The following is a summary of the responsibilities and tasks of the Center of Excellence grouped by skill-set. The CoE is in place to create a point of access to support the embedding of enterprise architecture and/or innovation tools. It is a combination of people, training collateral, discussion groups and support center to allow the wider user group to better use the tools. The CoE will be central to the transition of the product from one of data capture to one of pro-actively supporting the design process.

It is also best practice to start referring to the model rather than the tool, thus the benefit to an organization is not the tool but the effective use of the data within it and therefore it is the model that must be kept up to date not the tool.

By referring to the model there is generally better buy in from the users as inherently people equate learning how to use tools, even a simplified agile tool, with delay and they fail to see the benefit of the what an up to date model can bring. The CoE should provide all the base materials for new users to learn how to use the tool in the context of how to use the model.

Administration

The CoE is responsible for the administration of the software and user access, this is both a technical and business role. Firstly as an administrator to technically maintain the users, contributors and reviewers but also to understand the business needs of the platform to maintain the right mix of license types.

It is essential to align the use of communities on the platform with the structure of the users and so the CoE builds the community structure within the product to represent the business needs of either an innovation management or agile enterprise architecture initiative.

Modeling

The CoE oversees any modelling exercise and so is responsible for the data within the repository and its structure. This includes management of the meta-model, workspaces and ensuring data quality across the models.

The CoE should be involved early in the data collection process and so the initial modelling exercise including importing of data from existing sources and resolving issues of quality and consistency is an important aspect. However the maintaining data quality is something that must be addressed at all times.

The key areas of modelling responsibility can be broken down to the following:

• Importing data from different sources and building the initial models.
• Ensure the integrity of the models including reviewing and removing obsolete definitions and diagrams.
• Model Quality – especially do the models correspond to the methodology and approach of the business.
• Data Quality – Is the data complete or correct?
• Data Consistency – Is there duplicate data? Does a particular data item need resolution if defined in different ways by different parts of the organization.
• Working with subject matter experts to update the model.

Technical

The CoE role also oversees the technical aspects of the products and so there should be a deep knowledge of the functionality available and how it can be best deployed by the users. The CoE should look to attain a help desk level of support for the tooling, which would include the following:

• Managing Concepts and Associations
• Pairwise Comparison
• Kanban
• Charts and Pivot Tables
• Roadmaps
• Working with Diagrams

It is also important to know what maybe in the vendor feature pipeline and to get an early understanding of how new functionality can help the users.

Mentor and training

To ensure adoption of any software product there needs to be documentation. However, although software such as Corso’s is easy to adopt, effective documentation involves real world examples with data that a user readily understands and this is why we need to develop exemplar models that walk through the end-to-end modelling process.

The exemplar models must reflect a specific worked example that can be readily understood by the organization, including all expected meta-type and association examples but not too detailed. The same model can then be presented to different audiences as required in a kick off workshop. The following is an example agenda:

• Overview of the model and the process (5-10 minutes)
• Demonstration of the product capabilities (45 Minutes)
• New User start up – a document based walkthrough of the model incorporating how it can be manipulated in Corso Agile enterprise Architecture, this can double up as training materials and User Guides (3 hours)
• Training materials with step by step guide to product usage

The CoE will build the above materials and should distribute them through a shared portal with other supporting materials such as white papers and blogs to build an on-line community. The sharing of relevant information in a single location fosters the sense of community and is proven to improve the uptake of the software.

A combination of a physical CoE and an on-line portal ensure that there will be a place for current and potential users to go and find information as and when they need it.

Coordination

As Innovation Management or Agile Enterprise Architecture implementations become more mature they must also evolve. It is the CoE’s responsibility to manage this evolution in a structured manner. The CoE must:

Manage user requirements. New requirements will always come from users. These could be modified attributes, relationships, reports, Kanban, charts or Pivot Tables. Care must be taken to manage the changes strategically to keep the environment agile.

Agile EA must be embedded within the wider change process. The CoE must ensure that the Agile EA tool be embedded in the design process and PMO otherwise our models will remain isolated. The Roadmapping capability and use of Communities within a tool is key to supporting this.

Coordinate with Solution Architects to transition into using the tool for design. As part of incorporating the tools into the wider design phase solution Architects should be involved. The use of the workspace and Kanban capability to manage change around a particular context is key to supporting this.

Work with the vendor to understand how to phase these changes in and develop an internal roadmap for the tool roll out.

Selling

One last key but often-overlooked responsibility of the Center of Excellence is to internally evangelize the use of the tools and approach with current and future stakeholders. It is essential to build the CoE ‘brand’ within your organization.

Visibility will need to be earned by a strategic approach to getting the message across to the multiple stakeholders involved in the Innovation or Agile EA process. This can sometimes be a long process but with the right level of management commitment, a range of highly relevant materials and the enthusiasm to push things forward the CoE can flourish and provide a platform for a successful product implementation that provides tangible benefit.

The individuals responsible for the CoE should have multiple skills. These skills must include technical knowledge to understand the models themselves and to build technical teaching documents but there should also be an element of sales and project management.

Center of Excellence Return On Investment

The following started out as an exercise in understanding the value of building Architecture models and embedding these within the IT delivery process at a Dutch bank for a Portfolio Management project.

The following 5 measures were highlighted as potential cost savings, importantly each saving was small (2-5%) but when multiplied by the overall IT spend provided a strong case for the investment of resources and tools to build and maintain the model.

Improving The Architecture Process

• Using a central, repository based, multi-user enterprise architecture modelling solution (Agile Enterprise Architecture) enables clearer and controlled collaboration between different teams. This has shown improved project delivery times, with the added benefit of improved quality of information. Note the improvements and benefits will increase over time as ‘the organization’ becomes familiar with the new process and discipline.

• This is especially useful at the beginning of each project during the discovery of information stage.

• Direct benefit for ‘the organization’ is a 5% improvement on the costs of the architectural function in Design Authorities costs.

Project Governance

• In addition to using enterprise Architecture to govern the delivery of projects within ‘the organization’, there are additional benefits from the software delivery function working together with the Project Management Office in reusing across program architecture to derive shared technologies, solutions and processes across future projects.

• Benefit for ‘the organization’ is a 5% direct saving in investments made through the ability of making consistent technology buying decisions across total project spend across each ‘the organization’ business vertical/unit.

Mitigating Risk of Post Rework

• One of the common failings of project-by-project delivery is delivering in isolation and then having to rework changes.

• Having a single enterprise Architecture modelling tooling solution could deliver 3-5% improvement on project overspend by getting the full impact of changes understood prior to project initiation. In addition, money set aside to mitigate the risk of poor project delivery can be reassigned to money generating activities.

Removing Cost From The IT Landscape

• The core deliverables of a Portfolio Management project are still relevant over and above the broad cost savings from deploying an Agile Enterprise Architecture approach.

• With the ability of removing cost from the IT Landscape via a well developed and delivered enterprise Architecture program, as a by-process of better understanding the functionality of the IT Applications and associated annual Maintenance, ‘the organization’ will be able to remove overlapping applications, retire legacy systems, reduce maintenance and help implement a more service driven environment.

• Anticipated cost reductions across ‘the organization ‘would be 10% savings year in year IT support/maintenance costs.

Retention of Information

• Individuals who leave the organization or move to other roles take their knowledge with them which reduces the quality of the information. Maintaining a central repository of agreed and qualified artefacts will keep some of this information in the public domain and can be reused when delivering future projects.

• There is a potential 5% increase in the cost of architecture function.

One key objective of a business case is to persuade senior management to invest your organization’s limited resources, money and time into your project (work package), rather than in a competing one. Another driver of a business case is to aid you in thinking through and making sense of what you’ve been coordinating.

The business case is a necessity in order to secure the resources, allocation of operating funds, or capital investment in any project – especially when applying a new capability, product or major upgrade, or even buying up another company.

Every business case has a set of required inputs to make it successful. Here is an example list:

• Executive summary
• Work package or project name
• Business objectives and goals
• Market analysis
• Competitive analysis
• Capability or product description
• Target audience
• Sales and marketing plan
• Operational plan
• Complexity assessment
• Financial analysis, investment needs and break down and ROI
• Organizational areas affected (both internal and external), key stakeholders and dependencies
• Project or work package plan and schedule
• Required resources, including project management team, governance team, team members, funding
• Commitments required – project controls, reporting processes, deliverable schedule, financial budget schedule, roadmaps

A BUSINESS CASE SHOULD BE AGILE

It’s a big list. But most Enterprise Architects will already have this information documented in a model(s). If this were a list that you were working through without architecture, you’d struggle.

The intent of this list is good: business planning forces you to think through all the crucial elements of your delivery strategy. However, writing a business case that takes weeks or months to put together and is not based on facts, is a wasteful and costly exercise.

It can easily become a document that’s too big to read and too big to change. You need a more lean and systematic way to approach crafting a delivery strategy and constructing business cases. Something that:

• Is as collaborative as Google Docs to capture your vision, yet forces you to think through all the most important elements of any strategy
• Can be easily shared with others to get their feedback in a format they’ll actually read
• Provides a common language to discuss and debate strategy and architecture
• Supports quick updates with live collaboration to the original vision, as assumptions are validated and new updates refine the strategy

Essentially, you need something quick and efficient that will help you build your business case, whilst also getting traction with your internal stakeholders.

It is normal for business cases to go through a series of iterations of increasing depth throughout the innovation stage. A ‘high-level’ business case is often further refined in the lead-up to approval as assumptions, enterprise architecture assets and costs become more clear.

When you set out you may not know whether your business case will ‘make sense’, however by the time you finish you will have a detailed understanding of the business opportunities and risks for your project or work package. However, at this stage, you are still being agile and developing “just enough” detail to make decisions.

Here is our 6 point flow for how to build an agile business case:

1. DEFINE THE BUSINESS CASE SUCCESS CRITERIA

Many business cases evolved from one or more business ideas corroborated with some market research, subjective stakeholder feedback, and your gut feel or even a directive from a CxO. Understanding how the people who judge your business case will make their decisions is vital. If you don’t know what their criteria are, you’ll be unsure as to which business benefits you should aim for.

Your first step is to find a sponsor who cares about your success and who can provide guidance and support throughout the project and has the ability to drive change in your organization. Then you need to find out the timelines of what has to be done and by when.

Next, look at the scope and constraints you have to work within and any existing processes you need to follow. Are there any steps that you don’t need to do that will allow you to accelerate decision-making? For example, projects under $30,000 may not need executive approval.

The deliverable at this stage should be a plan that shows how you will develop and deliver the final business case. Create a mini-roadmap and model of the deliverables required using an ArchiMate or TOGAF model. Start by looking towards your program management office (PMO) for feedback on successful business cases, what has worked in the past, what are the common mistakes and pitfalls that they always see?

To build the view you need to be able to answer the following questions:

• What roles need to be involved in the business case team to produce the business case – e.g. a program manager?
• Are there any experts that you need direct access to?
• Is there an existing company process or template to follow?
• Are there any key dates for which the business case must be ready e.g. a stage, gate or quarterly meeting?
• Who are the key decision makers and what’s important to them?
• What deliverables need to be produced and by when?
• Are there any generally understood criteria that must be met, such as that all projects need to payback within two years and are aligned with the IT strategy?
• What format do stakeholders expect the business case to be delivered in? Presentation, spreadsheet, PDF or does it not matter?

1.1 UNDERSTAND YOUR VISION, GOALS AND DIRECTION

The first step is to write down your initial vision and start sharing it with stakeholders and partners for feedback. You can do this loosely or more formally using techniques such as the motivation extension in ArchiMate, or the business motivation model (BMM).

1.2 IDENTIFY KEY RISKS AND MYSTERIES

When a new idea or set of requirements arrive, many people go straight ahead and talk with their Engineering or IT department to get level of effort (LOE) estimates. It may be more important though, to validate your target customer segment and their problems.

Initially, just about every aspect of your outline vision can be considered risky. The riskiest parts of your work package will depend on how well informed your vision may be. For example, if your organization has already done extensive market research, maybe your market segment and their concerns are not the riskiest components of your plan. Maybe it’s the value proposition, your solution, or pricing model that may be the first things to corroborate.

You need to be able to quickly identify the riskiest parts that need to be tackled first so you can prioritize your work.

1.3 IDENTIFY KEY STAKEHOLDERS

The larger the organization you work in, the more stakeholders you’re likely to have. It’s important to identify who these folks are. Your enterprise architecture models will help you see who has the right competencies to help. If you’re not sure who your stakeholders are, then identify the most likely candidates and track their involvement.

2. COLLECT INPUTS

The next stage is about assembling and gathering the detail you need to prepare the business case. This is the data you will use to build both your financial model and documented rationalization. Some of this will be understood and modelled but the rest of it may need to be assumed.

In a small business you may do much of this yourself; in larger enterprises there are lots of other people to collaborate with. This is a chance to gather verification of your business case from within and outside the organization to support the rationalization that is made. This evidence must convince people that any assumptions are representative, sound and objective.

2.1 SYSTEMATICALLY TEST YOUR PLAN AND START GATHERING DATA

Having identified your key risks and assumptions, and who you think your key stakeholders are, you’re ready to start gathering qualitative and quantitative data.

For business strategy and market input you will need to talk to:

• People with access to market forecasts or research reports
• Anyone with access to competitor info (or research this yourself)
• The strategy team (or whoever owns the business strategy). In a smaller organization, the directors or executive team will be able to help
• Product marketing, to learn how your deliverables will be positioned against other products and propositions
• Marketing, to learn about any other planned launches or promotions that might compete for resources. (This may provide you opportunities to align and grab some of their resources)
• Business development, sales and channel managers

For program and project input you will need to talk to:

• Solution architects to see what is happening downstream
• Enterprise architects to see the impact of your work package on their work
• Portfolio managers to see what projects are in the current portfolio that may impact this business case (is there anything in the pipeline you can piggy back upon?)
• IT costs and any related research and development funding required.

For sales and revenue input you will need to talk to:

• Relevant sales channels to get a view of the sales they believe they could make
• Finance to get a view on metrics such as churn or ARPU (Average monthly Revenue Per User)
• Other successful business case owners to get their experience of take-up rates and also the assumptions they have used in their previous business cases

For cost input you must talk to:

• Development and/or suppliers
• Program management office to see potential costs of related resources
• Marketing to understand the cost of marketing activities such as launching and promotions
• Support functions to understand the cost of providing support e.g. any recruitment required, any necessary IT system updates

3. DEVELOP A MINI BUSINESS CASE

As early as possible, you need to produce a quick assessment on the business potential of the outcome of your work package to determine whether the idea is worth pursuing from a financial perspective.

This is particularly relevant if your organization, as part of its corporate strategy, has set minimum financial criteria on the types of business opportunities it’s willing to fund, and at what level it considers an investment a capital expense (Capex) vs. an operational expense (Opex).

This makes sense to do once you have some preliminary data on your target customer – specifically, the addressable market size and share you think you can capture; the viability of your pricing strategy and revenue model; and at least, high-level cost estimates. The numbers may be approximations, but they should be substantiated enough in reality to not be just guesstimates. Your data collecting activities from earlier should serve to inform this analysis.

An example mini business case outline structure follows:

1. Understanding Resistance

• What is the customer situation?
• What is the customer need?
• What is the customer resistance?

2. Our idea

• Description of the target audience
• Description of the new idea
• Is the deliverable new to us, new to the market, new to the world?
• Are we targeting an existing or new market?

3. This is the benefit for the customer

• Why will the customer choose this idea?
• What makes us unique?
• Who are our main competitors (if any)?
• What’s our positioning?
• What are our strengths and weaknesses?

4. We can produce, make or build it

• What is the viability of our deliverable?
• Who are the potential partners for co-creation?
• What are the next steps in the development process?
• Have we prototyped our concept?
• Do we know the impact of our concept on the organization/IT infrastructure?

5. This is what our company becomes/gets

• Potential turnover
• Potential margin and profits
• On-going costs for development and maintenance
• Other related benefits this work provides (cultural, social, new products/services)

6. How we will continue in this way

• Why proceed?
• What are the risks?
• Next steps: prototype/team-planning costs

This quick analysis is especially useful in early discussions with CFOs, the finance department, and business executives. It can also help with strategic prioritization discussions, and may be useful if your organization follows agile estimation techniques such as t-shirt sizing, Fibonacci sequence or powers of 2.

If you have many requirements or features that need prioritizing as part of a mini business case, it is worth looking at analytical hierarchy process (AHP). This will allow you to produce a summarized list of the priorities for your business case.

4.TRACK AND COMMUNICATE PROGRESS

The business case needs supporters both inside and outside the organization. You need to involve these people as collaborators and its useful if they are upstream, downstream and parallel to you in the business.

This helps you generate and sustain momentum for your work and enables them to feel part of the process. Your initiative gains further supporters and buy in.

The formation community empowers others to communicate about your initiative.

Here is where you can communicate using collaboration tools such as the Corso Strategic Planning Platform (SPP) that will enable stakeholders to be part of communities and are thereby part of your strategy and mission.

It definitely beats having to maintain presentation slides and emails.

As you validate your assumptions and de-risk your strategy, you can keep the community up to date of what’s happening. What’s more, you’re using formal techniques to describe the goals and strategy so they are consistent across other business cases ensuring they can be measured against each other.

Next, you need to produce the formal business case presentation.

As you continue to refine your deliverable and strategy through the activities above, you will be in a position to start writing an official business case, if such a formal document is really needed in your organization.

The difference now is that you will have not only validated inputs via data to ground your business case (like your companies financial figures), but also garnered the necessary “pre-support” to make a decision more of a formality.

5. DO THE ANALYSIS

During the analysis stage you study the inputs you’ve now gathered to build a detailed model of your product and your development project.

If you don’t have a tool that will allow you to model various scenarios and understand sensitivity analysis, you will need a spreadsheet. A typical business case financial model is broken down into a section on assumptions, a section on income (revenue), a section on costs and then a section that calculates the project value in terms of profit or payback.

You will find the following financial measures useful in any business case:

Net Present Value (nPV) – Measures the excess or shortfall of cash flows, in present terms, once financing charges are met. If the NPV is greater than 0, the project may be accepted; if the NPV is less than 0, then the project should be rejected.

Internal Rate of Return (IRR) – A rate of return used in capital budgeting to measure and compare the profitability of investments. It is defined as the annualized effective compound return rate

Return on Investment (RoI) – A measure of cash generated or lost due to the investment

Pay Back Period (PBR) – The period of time required for the return on an investment to ‘repay’ the sum of the original investment (Wikipedia 2011).

Total Cost of ownership (TCO) – the total value of acquisition and operating costs.

The above table contains a simple example of a financial analysis in a business case that requires a one off investment of 400,000 and generates revenue of 500,000 over 5 years.

We can see from this that the ROI is 25%. ROI is nothing more than a simple calculation using the following formula:

ROI = Gains – Investment Costs / Investment Costs = 500,000 – 400,000 / 400,000 = 25%

IRR is the internal rate of return. The IRR is a good way of judging different investments. First of all, the IRR should be higher than the cost of funds.

If it costs you 8% to borrow money, then an IRR of only 6% is not good enough!

IRR is also useful when investments are dissimilar.

Maybe the amounts involved are quite different or maybe one has high costs at the start, and another has many small costs over time.

The financials are only part of the business case but are certainly the first port of call for anybody analyzing the business case. You should treat the business case as a deliverable of your work package. There will be a cost for putting together the business case itself.

6.TELL THE STORY

The final stage of the business case process is to present or deliver the business case to the appropriate decision maker(s), whether this is an investment board or an individual.

No-one can predict the outcome with certainty, so your success rests on the credibility of the case you make – the suppositions you use, the proof you can gather, the support you line-up, the thoroughness of your analysis, and last but not least, your personal integrity.

This may be through a presentation where you have the chance to explain your business case in detail or through the delivery of a document for review.

If you’re not comfortable presenting, that’s okay. Why not find a stakeholder in the community that you feel can help add weight to your case? The challenge is to keep the story clear, objective and plausible. If a decision maker doesn’t understand it, they are unlikely to believe it and will find holes in your business case.

If you can, it is often worth petitioning decision makers before an approval process to see if they are on-board, if they have any concerns and if they judge that input from their areas has been satisfactorily characterized. Hopefully, you’ll have built up a good rapport in step 4 with your communities.

Primarily, a business case is a tool to sell your investment work package and outcomes (e.g. your new product, suggestion) to the business.

SUMMARY

There are always many ways to spend an organization’s money so most businesses have a standard process to produce business cases. The process normally includes the ability to compare one business case against another and to make it easy to say ‘yes’ to the right ones, and ‘no’ to the wrong ones. Often these decisions are owned and governed by the program management office (PMO).

A good business case should provide you with a significant advantage in the context of other projects. Following the six steps should ensure that a rigorous assessment of a new work package has been completed and has provided a level of investigation and analysis that should ensure (as far as is possible) the outcome is a success.

In an perfect world, the financial model, its assumptions become a tool that can be used to manage the work package through it’s life time.

Most organizations operate at a fast pace of change. Businesses are constantly evaluating market demands and enacting change to drive growth and develop a competitive edge.

These market demands come from a broad number of sources, and include economic changes, market trends, regulations, technology improvements and resource management. Knowing where the demands originated, whether they are important and if they are worth acting on can be difficult.

We look at how innovation, enterprise architecture and successful project delivery needs to be intertwined and traceable.

In the past, managing ideation to the delivery of innovation has not been done or has been attempted in organizational silos leading to disconnections. This in turn results in change not being implemented properly or a focus on the wrong type of change.

How Does An Organization Successfully Embrace Change?

Many companies start with campaigns and ideation. They run challenges and solicit ideas from within and outside of their walls. Ideas are then prioritized and evaluated. Sometimes prototypes are built and tested, but what happens next?

Many organizations turn to the blueprints or roadmaps generated by their enterprise architectures, IT architectures and or business process architectures for answers. They evaluate how a new idea and its supporting technology, such as SOA or enterprise-resource planning (ERP), fits into the broader architecture. They manage their technology portfolio by looking at their IT infrastructure needs.

Organizations often form programme management boards to evaluate ideas, initiatives and their costs. In reality, these evaluations are based on lightweight business cases without the broader context. Organizations don’t have a comprehensive understanding of what systems, processes and resources they have, what they are being used for, and how much they cost and the effects of regulations.

Projects are delivered and viewed on a project-by-project basis without regard to the bigger picture. Enterprise, technology and process-related decisions are made within the flux of change and without access to the real knowledge contained within the organization or in the market place. IT is often in the hot seat of this type of decision-making.

Challenges Of IT Planning

IT planning takes place in reaction to and anticipation of these market demands and initiatives. There may be a need for a new CRM or accounting system, or new application for manufacturing or product development.

While IT planning should be part of a broader enterprise architecture or market analysis, IT involvement in technology investments are often done close to the end of the strategic planning process and without proper access to enterprise or market data.

The following questions illustrate the competing demands found within the typical IT environment:

How can we manage the prioritization of business, architectural-and project-driven initiatives?
Stakeholders place a large number of both tactical and strategic requirements on IT. IT is required to offer different technology investment options, but is often constrained by a competition for resources.

How do we balance enterprise architecture’s role with IT portfolio management?
An enterprise architect provides a high-level view of the risks and benefits of a project and the alignment to future goals. It can illustrate the project complexities and the impact of change.

Future state architectures and transition plans can be used to define investment portfolio content. At the same time, portfolio management provides a detailed perspective of development and implementation. Balancing these often-competing viewpoints can be tricky.

How well are application lifecycles being managed?
Application management requires a product/service/asset view over time. Well-managed application lifecycles demand a process of continuous releases, especially when time to market is key.

The higher level view required by portfolio management provides a broader perspective of how all assets work together. Balancing application lifecycle demands against a broader portfolio framework can present an inherent conflict about priorities and a struggle for resources.

How do we manage the numerous and often conflicting governance requirements across the delivery process?
As many organizations move to small-team agile development, coordinating the various application development projects becomes more difficult. Managing the development process using waterfall methods can shorten schedules but can also increase the chance of errors and a disconnect with broader portfolio and enterprise goals.

How do we address different lifecycles and tribes in the organization?
Lifecycles such as innovation management, enterprise architecture, business process management and solution delivery are all-necessary but are not harmonized across the enterprise. The connection among these lifecycles is important to the effective delivery of initiatives and understanding the impact of change.

The enterprise view, down through innovation management, portfolio management, application lifecycle management and agile development represent competing IT viewpoints that can come together using an ideas to delivery framework.

Agile Development And DevOps

A key component of the drive from ideas to delivery is how strategic planning and the delivery of software are related or more directly the relevance of Agile Enterprise Architecture to Devops.

Devops is a term that has been around since the end of the last decade, originating from the Agile development movement and is a fusion of Development and operations. In more practical terms it integrates developers and operations teams in order to improve collaboration and productivity by automating infrastructure, workflows and continuously measuring application performance.

The drivers behind the approach are the competing needs to incorporate new products into production whilst maintaining 99.9% uptime to customers in an agile manner.

To understand further the increase in complexity we need to look at how new features and functions need to be applied to our delivery of software. The world of mobile apps, middleware and cloud deployment has reduced release cycles to weeks not months with an emphasis on delivering incremental change. Previously a business release would be every few months with a series of modules and hopefully still relevant to the business goals.

The shorter continuous delivery lifecycle will help organizations:

• Achieve shorter releases by incremental delivery and delivering faster innovation.
• Be more responsive to business needs by improved collaboration, better quality and more frequent releases.
• Manage the number of applications impacted by business release by allowing local variants for a global business and continuous delivery within releases.

The Devops approach achieves this by providing an environment that:

• will minimize software delivery batch sizes to increase flexibility and enable continuous feedback as every team delivers features to production as they are completed.
• has the notion of projects are replaced by release trains which minimizes batch waiting time to reduce lead times and waste.
• has a shift from central planning to decentralized execution with a pull philosophy thus minimizing batch transaction cost to improve efficiency.
• makes Devops economically feasible through test virtualization, build automation, and automated release management as we prioritize and sequence batches to maximize business value and select the right batches, sequence them in the right order, guide the implementation, track execution and make planning adjustments to maximize business value.

Figure 1: DevOps lifecycle

Thus far we have only looked at the delivery aspects, so how does this approach integrate with an enterprise Architecture view?

To understand this we need to look more closely at the strategic Planning Lifecycle. Figure 2 shows how the strategic planning lifecycle supports an ‘ideas to delivery’ framework.

Figure 2: The strategic planning lifecycle

You can see here, the high level relationship between the strategy and goals of an organization and the projects that deliver the change to meet these goals. The enterprise rrchitecture provides the model to govern the delivery of projects in line with these goals.

However we must ensure that any model that is built must be just enough EA to provide the right level of analysis and this has been discussed in previous sections of this book regarding the use of Kanban to drive change.

The Agile EA model is then one that can both provide enough analysis to plan which projects should be undertaken and then to ensure full architectural governance over the delivery. The last part of this is achieved by connecting to the tools used in the Agile space.

Figure 3: Detailed view of the strategic planning lifecycle

There are a number of tools that can be used within Devops. one example is the IBM toolset, which uses open standards to link to other products within the overall lifecycle. This approach integrates the Agile enterprise Architecture process with the Agile Development process and connects project delivery with effective governance of the project lifecycle and ensures that even if the software delivery process is agile the link to Goals and associated business needs are met.

To achieve this goal a number of internal processes must interoperate and this is a significant challenge, but one that can be met by building an internal centre of excellence and finding a solution by starting small and building a working environment.

The Strategic Planning Lifecycle Summary

The organization begins by revisiting its corporate vision and strategy. What things will differentiate the organization from its competitors in five years? What value propositions will it offer customers to create that differentiation? The organization can create a series of campaigns or challenges to solicit new ideas and requirements for its vision and strategy.

The ideas and requirements are rationalized into a value proposition that can be examined in more detail.

The company can look at what resources it needs to have on both the business side and the IT side to deliver the capabilities needed to realize the value propositions. For example, a superior customer experience might demand better internet interactions and new applications, processes, and infrastructure on which to run.

Once the needs are understood, they are compared to what the organization already has. The transition planning determines how the gaps will be addressed. An enterprise architecture is a living thing with a lifecycle of its own.

Figure 3 shows the ongoing EA processes. With the strategy and transition plan in place, eA execution begins. The transition plan provides input to project prioritization and planning since those projects aligned with the transition plan are typically prioritized over those that do not align.

This determines which projects are funded and entered into, or continue to the Devops stage. As the solutions are developed, enterprise architecture assets such as models, building blocks, rules, patterns, constraints and guidelines are used and followed.

Where the standard assets aren’t suitable for a project, exceptions are requested from the governance board. These exceptions are tracked carefully. Where assets are frequently the subject of exception requests, they must be examined to see if they really are suitable for the organization.

If we’re not doing things the way we said we want done, then we must ask if our target architectures are still correct. This helps keep the EA current and useful.

Periodic updates to the organization’s vision and strategy require a reassessment of the to-be state of the enterprise architecture. This typically results in another look at how the organization will differentiate itself in five years, what value propositions it will offer, the capabilities and resources needed, and so on. Then the transition plan is examined to see if it is still moving us in the right direction. If not, it is updated.

Figure 3, separates the organization’s strategy and vision, the enterprise architecture lifecycle components and the solution development & delivery. some argue that the strategy and vision are part of the EA while others argue against this. Both views are valid since they simply depend at how you look at the process.

If the CEO’s office is responsible for the vision and strategy and the reporting chain as responsible for its execution, then the separation of it from the EA makes sense. In practice, the top part of the reporting chain participates in the vision and strategy exercise and is encouraged to “own” it, at least from an execution perspective.

In that case, it might be fair to consider it part of the EA, or you can say it drives the EA. The categorization isn’t as important as understanding how the vision and strategy interacts with the EA, or the rest of the EA, however you see it.

Note that the overall goal here is to have traceability from our ideas and initiatives, all the way through to strategic delivery. This comes with clear feedback from delivery assets to the ideas and requirements that they were initiated from.

This post addresses the capabilities and requirements for enterprise architecture workspaces & versioning. When envisioning and planning out any initiative, especially an architectural driven one, its important to keep an overall enterprise blueprint (model) up to date and maintained. Various initiatives and plans may impact upon the blueprint over its lifetime.

As an enterprise evolves, then so does its architecture. A strategy for maintaining the enterprise architecture over its lifetime (the baseline) is important to allow change to be driven in the context of everything else.

Detail and Techniques for EA Workspaces & Versioning

There are a number of techniques that are necessary to manage architecture over time. It’s important to understand the enterprise baseline, workspaces, baselines, merge and extract, workspace compare, concept versioning, concept compare, communities. The following sections detail each of these topics and why they are important and how they work together.

Dealing with Change

When we look at change within the context of innovation management and/or enterprise architecture, we can see that change is continuous, slower (than change in software development) and often has a medium-high approval cycle (governance).

There is also a need to manage access to information through community groups so that some aspects of the detail cannot be changed or viewed without permission. Proposals for change can take the form of multiple plans, option and programs that are proposed.

One of the main deliverables for an architecture blueprint is a set of recommendations and constraints and some idea of how to transition and decide between blueprints and different alternatives. The outputs of these alternatives maybe Time lines/Roadmaps, costs and resource.

An organization may move through different lifecycles at different phases of their enterprise architecture practice.

For example, within the TOGAF ADM, different iterations and approval lifecycles may be carried out.

Architecture context is setting the context of the architecture initiative. Architecture definition is about defining and iterating through the domains of architecture. Transition planning is focusing on moving from one state of the architecture to another. And, governance is about applying management and sign-off activities to architecture initiatives.

Enterprise Baseline

As an organization matures its architecture over time, a published version of the architecture should be made available. This will normally be done as a major release.

An enterprise baseline is a continuous moving target. In TOGAF terms, the continuum. That is, we would never roll back to a baseline without losing all of the descendants of the baseline. It is best practice to create a copy of a workspace of the baseline and increment that with a major version number.

In a simple ‘as is’ and ‘to be’ scenario (Figure 2), we may decide to outsource some of our data and systems management. Two alternative architectures may be examined and one chosen as the outcome.

Whilst alternative X and Y may be compared for value, the current architecture is baselined. When Y is chosen, it becomes the new baseline. This is an extremely simple way of managing architecture. At this point, we can publish the new baseline to the organization.

However, in most instances, management of the baseline and alternatives are far more complex. Figure 3 shows some example implementation and migration patterns for innovation management and enterprise architecture.

Workspaces

Workspaces can equate to the Plateau concept in ArchiMate. However, we’ve used the term workspace as it has a wider meaning. A workspace is defined as a relatively stable state of the architecture that exists at a moment in time. A workspace can represent either current, future or transition architecture. By nature, workspaces are hierarchical.

Transition workspaces represent the enterprise at incremental states reflecting the periods of transition between a current and future architecture (sometimes called baseline and target architecture). A current and future architecture may have many transition workspaces between them showing alternative ways that a future architecture may be achieved.

Transition workspaces are used to allow for work packages and projects to be grouped into managed portfolios and programs, demonstrating the business value of each transition. Workspaces should be created from other workspaces to create hierarchies and lineage. In this manner, workspaces can be used for decision making about alternatives.

Baselines

When a workspace exists for a limited time and is unlikely to be changed, we can baseline the architecture. Once architecture has been baselined, it should not be modified again, instead, it should flow to new target architecture. All changes should be made in the target architecture.

You should be able to view any baseline for historical purposes and to compare to the any other workspace.

Merge and Extract

In order to copy concepts between workspaces, its important to be able to merge into your current workspace or to extract out of your current workspace. Each concept you define should have a unique identifier. The identifier shouldn’t be the name.

When a concept is copied to another workspace (or made available to a workspace), it should retain its lineage. Workspaces that are baselined cannot have concepts copied into them.

Lineage, Workspace Compare and Gaps

When a concept exists within multiple workspaces, and the lineage has been created from workspace to workspace, then a compare can take place between two or more workspaces. Lineage is an extremely important concept. Much like human ancestors have lineage (grand parents, children, siblings etc.), concepts can have lineage.

The lineage is maintained through a concepts identifier. This means that even if a concept changes name between workspaces, we can still compare the concept by tracing its lineage up and down the workspace hierarchy.

A gap is the difference between two workspaces or plateaus. A gap usually shows what was created, updated or deleted between two workspaces. A gap is closely tied to a work package as it may instantiate a set of work to be done.

A comparison between two workspaces can automatically produce the contents of the gap and the created, updated or deleted status of the gap. Again this helps with project and portfolio management when assessing initiatives and work.

Concept Versioning

Concepts within their own right may be versioned. When a new version of a concept is produced, the current version of the concept is baselined. The concept baseline stores all of the associations that the concept currently has in that version, including the destination concepts at the end of an association. Version numbers are incremental and usually system generated.

A user may work on the current version and can see the previous versions for reference purposes.

A model is a network of concepts and other concepts will have their own associations. The current version of a concept only includes its immediate relatives. This is very similar to a configuration set in version control systems. In a team environment, concepts that are related via other concepts may well have been changed at a different time, in a different workspace or completely removed.

In Figure 5, we can see that the account management business capability has its own set of associations but these are not part of the CRM system version. If a concept version is rolled back to a previous version then all of its immediate relatives are rolled back to but not their associations.

If a concept has been removed, it is put back in place. If an association was removed it is added back. The implication of this is that rolling back a version of a concept may change the semantic meaning of the overall model as in Figure 6.

In Figure 7, Account Management had Account Manager associated with it.

If CRM system is rolled back to version 1 from version 2, then the new model looks like this example. There is a balance between base lining workspaces (entire configuration sets) and individual concepts.

Concept Compare

It is useful just to compare the lineage of a single concept anywhere.

Where used

In its simplest form, a ‘where used’ report is useful to show which concepts are in which workspaces and what their version numbers are. This report also makes use of lineage. This provides a view of all possible initiatives a particular concept is involved in and therefore an understanding of cross project or program dependencies.

Version Compare

Versions of concepts can be compared. The comparison will show the associations and concepts that have been created, updated or deleted for each version. A concept can be compared for two or more versions of the concept including the current version.

Concept compare is very different to a workspace compare. Workspace compare is about finding differences and gaps with a view to planning out work. Concept compare is about understanding what has changed and why.

Communities

Community access to workspaces and concepts needs to be managed. Access control is critical. some workspaces may be created purely for protecting access privileges. For example, an organization may have an initiative to reduce head count for a particular part of the business in order to streamline it. However, this alternative should not be visible to all stakeholders. A community can be set up and assigned as a private community to work with this alternative workspace.

In Summary

The use of workspaces, baselines, and comparisons is essential for bridging the gap between the architecture of the enterprise and the architecture of a particular solution or initiative. As part of the architectural planning process we need to be able to manage parallel solutions whilst retaining the relationship with the enterprise continuum.

Back in March at our erworld virtual conference, I participated in a DM Radio session that discussed the reality of living in a hybrid data world. It was interesting and eye-opening in many ways, yet confirmed what I always believed – Big Data is a reality (no surprise) but companies are still living in a “Small Data” world from an operational perspective (still no surprise, but it’s good to have it confirmed).

In today’s technology-driven business environment it’s clear that no organization can survive and thrive without a focus on three core pillars – Agility, Speed and Innovation. Business leaders already recognize the significance of technology in delivering these capabilities to remain competitive and get ahead of the competition, but how can enterprise IT teams deliver?

Research by the BPI Network shows that almost 70 percent of business leaders believe enterprise IT has become “far more important” in the past five years. Yet, less than half believe their ability to innovate is good or very high. How can IT groups deliver more transformation objectives required by the business?

Now is the time to embrace the three pillars of Agility, Speed and Innovation, as we see unprecedented acceleration in the rate of changing in the business environment. This is made all the more important when considering that enterprise IT is such a fundamental function of so many businesses, and those where it isn’t are actively playing catch up.

Organizations need to empower their IT teams to drive and apply these principles. Enterprise Architects especially, should have the pillars foregrounded in their consciousness, acting on these principals at all times.

Agility

Firstly businesses needs to be agile, and ready to respond to changes. In a Dimension Data study, findings indicated that on site data storage is “fading into the category of legacy technology as new cloud-based capabilities provide better performance in many cases,  and at a much lower cost.” This is important for two main reasons.

One, businesses are incentivized to move to the cloud because it will save them money. Not only is cloud storage cheaper than setting up a data center, their ‘shelf-life’ (so to speak), is much longer, and requires little-to-no upkeep from the business.

Secondly, cloud based data increases agility exponentially, with businesses potentially having a world’s worth of data available at their fingertips, almost instantaneously.

The same study also found that business leaders, frustrated with a lack of progress in the field, were migrating to ‘Shadow IT,’ referring to Software-as-a-Service based set ups. The fact that so many business leaders are now favoring this approach, is indicative of both the need to be agile, and the agility cloud storage can offer.

Speed

The speed pillar focuses on how fast a business can respond to changes. If agility describes being ready to respond to changes, this pillar is how quickly a business can launch the new systems, product lines and other revisions.

For an example of the speed pillar in action, one could look at a key pillar in modern technology innovation – Apple. The tech giant brings new products to market at a nauseating frequency, allowing them to respond quickly to competitors innovations, whilst simultaneously (and regularly), introducing their own new ideas.

Therefore, one of the main positives associated with this pillar, is that a business is both less likely to fall behind the curve, and more likely to be ahead of it. If that coincides with an insatiable consumer desire for better, and more functionality (which it does, for Apple at least), it’ll likely mean higher sales.

Good leveraging of roadmapping (the enterprise architecture kind, not the atlas crafting) is a great best practice to stay on top of this pillar.

In roadmapping, Enterprise Architects (EAs) provide a set of views corresponding to the business and IT infrastructure that allow a company to see where they are today and where they want to be in the future.

This preparation is integral to managing a constructive time to market.

Innovation

Lastly, we have the innovation pillar. Unlike the other two pillars, which are in essence, defensive, reactionary responses, innovation could be described as ‘aggressive’. With innovation, great innovation particularly, you are the disruptor. Your innovation is what worries your competitors. By definition, innovation means that you’re already out in front, with everybody else playing catch up.

Business leaders need to start pushing for further IT innovation funding. Life is becoming more and more entwined with technology, with the market growing exponentially in recent years. Even products and services that existed previously without any aid from the enterprise IT team aren’t immune.

The boom in Internet of Things (IoT) devices has led to a wealth of internet connected products that wouldn’t have been before. And in any case, even if a business has opted out of adopting an IoT model up to now, their systems and internal happenings will more than likely be rooted in technology.

And then there’s the argument to re-purpose the Chief Information Officer as the Chief ‘Innovation’ Officer. Even if businesses are yet to outwardly make that change, there are clear signs that it’s already happened, with “46% of Elite 100 companies prioritizing the introduction of new IT-led products or services.”

Richard Garratt, Director of Next Generation Data Centers at Dimension Data Americas, said driving change requires “some business process change. It requires new skill sets for the corporate IT departments in how they interact with business units. And it requires a change in thinking on the role of IT in the organization versus the historical role, which was really very infrastructure-geared.”

Information Technology is where innovation needs to happen, and where innovation should begin.

So does that mean innovation is the most important pillar?

Not necessarily. Many established businesses can still thrive without constantly innovating. Evidence of this can be found all over San Fransico’s tech-mecca, Silicon Valley. This is where the innovation is happening, yet often times, it is established businesses that reap the rewards. The MicroGoogApples of the world buy into these startups to add new, or strengthen current arms of their organization. Now we can hardly call corporate acquisitions, ‘innovative,’ can we?

But that doesn’t mean it’s irrelevant either. None of these pillars are recipes for success in isolation. Innovation is incredibly well suited – scratch that – essential, to startups and newer, smaller businesses. This is because gaining market share is extremely difficult, and oftentimes, creating a new market to thrive in is easier than prying it from stubborn hands.

However, once a position within a market is secure, innovation shouldn’t stop. For a start, the over-whelming majority of businesses won’t be able to get anywhere near the capital required to buy out a promising start-up, and even those few businesses that do, the large costs still make innovation a priority.

The other two pillars can’t flourish alone either. Having the agility and preparedness to respond to change is great, but if your changes don’t see or affect the market for another year, the likelihood is that you’ll be fighting for market scraps, before running off to your old friend, the innovation pillar again.

The reverse goes for speed. The ability to get new products to market, or implement new changes to business infrastructures quickly, is close to redundant if you don’t have the agility and foresight to start rolling out new procedures when called upon.

Be honest with yourself. Is your business applying these three pillars as it should be? If not, how will you get there?

In my role as Product Marketing Manager for erwin Modeling, I have the pleasure of attending many industry and vendor-sponsored events related to the practice of data management. However, as a representative for a software solution vendor, I often feel like my fellow attendees are taking me “with a grain of salt” because I am perceived as being there to move product.  While understandable, it still hurts, as our philosophy within the erwin Modeling team has always been that if you focus on delivering true value, the product will move itself.

Gamification brings elements of traditional game play to drive engagement and behavior. Traditionally, engagement of stakeholders has been critical to the success of innovation and enterprise architecture initiatives.

Game players typically exhibit persistence, risk taking, attention to detail and problem solving. All behaviors that would ideally be suited to management of EA and IM.

Many EA projects fail through disengagement of the wider community. Innovation efforts can suffer from a lack of persistence in taking a qualified idea through to delivery. Gamification can help by providing mechanisms to engage and retain communities through these endeavors.

Gamification Detail & Techniques

There are really 4 objectives that we’re looking to address with gamification:

• Fostering engagement
• Inspiring loyalty
• Increasing conversions
• Building a community

The objectives help us to make our innovation management and enterprise architecture practices a success.

Fostering Engagement

We want to engage as many stakeholders as possible and we want them to add value to our programs. We can encourage various behaviors whereby stakeholders want to return and contribute. We can also provide key performance indicators that demonstrate the success of our engagement strategy. Examples of behaviors that foster engagement:

Behavior	KPI
Posting a comment	Number of comments
Writing a blog post	Number of blog posts
Reading existing content	Number of page views
Voting on content	Number of votes
Rating content	Number of ratings entered

Inspiring Loyalty

When we want to encourage users to use a feature, we can encourage various behaviors to inspire them to use the platform more often. We can also inspire loyalty around themes such as innovation management campaigns. Example behaviors that inspire loyalty:

Behavior	KPI
Acquiring more users	Number of new users
Logging in	Number of new login’s
Viewing a page	Number of page views

Increasing Conversions

The big problem with conversions is the catch-22 situation of attracting stakeholders and converting them to reviewers of your EA and IM content. Without collaboration you can’t attract users, and without users you don’t get collaboration. So how do you get people to collaborate time and again? Example behaviors that increase conversions:

Behavior	KPI
Exploring various different EA and IM views	Number of page views of EA and IM views
Visiting other users’ content	Number of page views of others’ content
Reading comments of the content	Number of page views of comments

Building Communities

Innovation management and agile enterprise architecture requires the input of a community of stakeholders. But how do you build a community and how does gamification help? The following behaviors all help build a community. Example behaviors that build communities:

Behavior	KPI
Leaving comments	Number of comments
Writing reviews	Number of reviews
Giving a ‘thumbs up’ or ‘high five’	Number of ‘thumbs up’ or ‘high fives’
Asking a question	Number of questions asked
Answering a question	Number of questions answered
Sharing an idea	Number of ideas shared

Gamification Missions & Challenges

Missions and challenges are synonyms in gamification. They require users to perform a prescribed set of game play actions, following a defined route. A mission might involve a single step (for example, entering an idea) or several steps.

Often, the steps in a mission must occur in a certain sequence. These missions are called progression missions. other times, actions can occur in any sequence. These are called random missions.

The tasks in a mission might revolve around the same game play behavior (reading five posts, for example), or could involve different game play behaviors (for example, viewing a diagram, commenting on a diagram, adding a concept to a diagram and adding your own diagram).

When these techniques are used within a platform, an organization can design their own missions and objectives that satisfy their particular business goals (for example, a mission to ensure that stakeholders respond to a campaign in innovation management).

Gamification can be visualized in a number of ways. These include leader boards, badges and enhanced profiles for users within a community.

Badge Themes

There are various elements of gaming that we can harness for enterprise architecture and innovation management purposes. Some example badges and rewards:

Cascading information: Unlock information continuously

Investment: Feel pride in your work in the program

 

	Bonuses – receive unexpected rewards		Achievements – earn public recognition for completing work
	Countdown – tackle challenges in a fixed amount of time		Appointments – check in to receive new challenges
	Discovery – navigate through learning and unpick areas of knowledge		Collaboration – work with others to achieve goals
	Loss aversion – play to avoid losing what you have gained		Epic meaning – work to achieve something sublime or transcendent
	Infinite play – play continuously until you become an expert		Virality – be incentivized to involve others
	Synthesis – work on challenges that require multiple skills to solve

 

Progression: Success can be visualized incrementally

 

Levels – ramp up and unlock content

Points – increase the running numerical value of your work

Thus we can see that many of the elements in gamification can be tied directly to some of the pain points that are experienced in enterprise architecture and innovation programs.

Summary

Although, it may seem like gamification requires you to have an interactive way for your stakeholders to participate, there are more convenient ways you can use this strategy and apply it to your innovation management and enterprise architecture as a very powerful tool.

Many organizations might use this in a manner such as having online tooling that offers badges and points, but without tooling you can also benefit from this in different ways.

Make sure you always have your campaigns or architecture KPIs updated and share them on social media. Most companies opt for sharing this on internal social media platforms such as Yammer or SharePoint and using gamification on other social media platforms as well.

Remember that you don’t have to use gamification; it depends on your organizations’ culture.

As the general manager of a software business I am always engaged in heated battle with my solution’s competition. We at erwin compete to have the best product, the best partners, the best people and of course, the best customers. As the #1 data modeling solution in the market it’s clear we’re doing something right and I’m proud of our successes. Competition is good and it’s healthy for the marketplace.