Change Management for Project Managers

Why Project Managers are evolving to Change Managers

Projects and Programmes - What is the key focus?

If you happen to work on project or programme management and you like to excel at what you do, you almost certainly concluded long ago, that you cannot focus just on the triple delivery constraint of scope-time-cost. 

Sponsors have an obligation to continuously monitor the desired project output

As a Project Manager - you did everything right but your project was considered a failure. Countless project managers have delivered their projects on time, on track and on target, and still they were not applauded by their top management, who considered the project to be a failure.

This is extremely frustrating for project managers, who in such a scenario, would have done nothing wrong.  Their line managers, whether programme managers or sponsors, have the obligation to continuously monitor the desired project output, ensuring it remains relevant and a contributor to the expected programme outcome.  

Typically, Projects deliver outputs and Programmes deliver outcomes

It is worthwhile stressing that, typically, projects deliver outputs and programmes deliver outcomes – read benefits realisation.  Obviously, large-scale transformation projects, set up individually and not integrated in a programme, can also deliver outcomes, but these would not be a majority. 

Aligning to strategic objectives with an agile approach

For programmes to deliver the expected outcome and realise the desired benefits, they must be fully aligned with the strategic objectives set out by the organisation.

Two decades ago, Strategic Planning would define 5-year objectives and roadmaps. Things have changed significantly, and Strategies are now “living organisms”, that continuously morph and adapt to ever-changing challenges and new predators in each sector.

What then, is the impact of programmes, caused by this dynamic of change?  How can programmes cope with the new strategic requirements?  What is the impact on defining the expected outcomes, and qualifying and quantifying the desired benefits?

The obvious response is “agility”.  No, you did not read “all projects must become Agile”. Agility is a mindset, not a manifesto or a methodology.  It is simplifying processes and flattening governance structures, and not eliminating them altogether. Agility is working together, at all levels and in all functions, to make the whole organisation nimbler, and more malleable. Resilience is also a very important factor to endure permanent change. 

Portfolio Management

This is where portfolios come into action.  The portfolio management function works back-to-back with the core leadership of the organisation, to understand strategies and objectives, and ensure these are translated into operational guidelines for programmes and projects.

Portfolios scrutinise, assess, measure, estimate, etc, and ultimately sift the programmes and projects selected to implement the strategy.  Are project's outputs contributing to programme's outcomes, and programme's outcomes aligned with the strategy?  Do projects and programmes have the elasticity and ductility necessary to react, pivot and transform, to ensure continuous alignment to (everchanging) strategies?

Portfolios are responsible for creating the conditions and setting up the scene that allow programmes and projects to flourish and strategies to be brilliantly implemented.  Through Maturity Assessments, portfolios map out the existing Company Culture and Governance and Assurance Frameworks.  Similarly, Capability Assessments determine the current aptitude of the resources available, to undertake strategy implementation. A gap analysis exercise will determine the effort and time required to evolve from present to future states.

The impact of Change Management on Projects, Programmes and Portfolios

Hence, if Portfolios are responsible for preparing People and Organisations for change, how can they actually do it?  None of this is easy but, still, it is easier to prepare organisations for change, than People.  There are a number of assessment models and approaches available, but I personally recommend the Praxis Framework and, specifically on Business Integrated Governance, the model developed by the CoreP3M Data Club, also featured in Praxis.  

The million-dollar question is: “How can leaders work with people, to grow the company-wide agility mindset and nourish the resilience to change of all elements in the team?”.  This is not an easy ask. People don’t mind change, they just don’t want themselves to have to change along with it. But the fact is that they do. Oh yeah, they certainly do. So how can leaders lead people to change?  How can leaders drive people into scenarios of permanent mutation?  How can people trust change and feel safe again? What are the new foundations of individual and family stability?  

The role of the Leader

Maslow would say that safety contributes to happiness. I say that happiness contributes to productivity and to generating value.

A leader’s mission is therefore to make people happier.  This applies to executive managers, to portfolio, programme, project managers, and to business-as-usual managers.  In fact, it applies to all leaders in the organisation.

Effective and efficient change requires alignment with strategy, flexible delivery, and benefits realisation.  All these require people to embrace change.  People that not only are willing to change, but that are the change. 

Is it a case of “the Project Manager is dead, long live the Change Manager”?  No, not at all.  It’s a case where all Project Managers must also change, and (also, not instead) become Change Managers. Project and Programme Managers need one more layer of competency, a new mindset – Change Management.  

The same way outputs are way less important than outcomes, processes and tools are way less relevant than people. People deliver outcomes. People deliver change. By improving their people management skills, leaders will master the delivery and management of effective and efficient change.

Source: apmg-international.com

Continue reading

Using PRINCE2 at NatureScot Case Study

NatureScot is the Scottish Government’s agency for all matters relating to nature, and one of its responsibility’s is to organize Green Infrastructure Strategic Intervention (GISI) projects. This paper explores how PRINCE2 was used to organize the Knowledge Exchange event, which intended to create networking opportunities for those involved in GISI projects.

The paper will also discuss how specific PRINCE2 principles were applied to the project, specifically to unexpected events.

Case Study

1. Introduction

NatureScot is the Scottish Government’s agency for all matters relating to nature. Our website is at Nature. Scot, which also hosts our Green Infrastructure Strategic Intervention (GISI) project pages.

As Green Infrastructure Project & Funding Officer at NatureScot, I am the first point of contact for the following:

◉ Eight construction projects that are creating or improving greenspace and other green infrastructure in areas of multiple deprivation in urban Scotland.

◉ Six community engagement projects.

◉ Communications to encourage the mainstreaming of green infrastructure.

The GISI is a £16 million European Regional Development Fund (ERDF) that NatureScot manages on behalf of the Scottish Government. The 15 capital projects supported by the fund are predominantly managed by local authorities, but three are managed by housing associations, and one by an NHS Board. They fit well within the PRINCE2 definition of a project because they are all temporary and are delivering a specific change in-line with a business case.

The GI Community Engagement Fund is smaller (£0.5 million) and supported 11 applications to increase involvement in greenspace, within areas of multiple deprivation. Nine of these proposals were delivered by charities. These grants did not closely align with the definition of a PRINCE2 project, because they were much more closely linked to business as usual (BAU) for the applicants. The exception was a pilot to work with a discrete community to design and install a ‘raingarden’ to reduce surface water flooding within a small area beside two tower blocks.

2. Background

In Scotland, the mainstreaming of Green Infrastructure (GI) into projects is behind London and mainland Europe, and actors tend to work in isolation, even though they have good links with EU and global networks. In order to address this, one of the objectives of the GISI is to encourage a network of actors in the GI field to reduce siloed working and increase momentum towards mainstreaming GI in Scotland.

Green infrastructure (GI) is the network of multifunctional greenspace and other vegetated features, and is being increasingly recognized as as important as ‘grey infrastructure’ such as roads, sewage networks, etc. GI can address multiple problems faced by society in the face of climate change and biodiversity loss. A well-designed and maintained GI has been proven to improve mental health, help with urban cooling, maintain good air quality, reduce surface water flooding caused by extreme rainfall, and encourage active travel when integrated with active travel networks.

The Knowledge Exchange project was part of a programme to fund GI projects, best called the Green Infrastructure Strategic Intervention (GISI).

Main stages of the GISI	Dates
Test market for grant intervention	Sept 2013 to Dec 2014
Develop fund criteria, processes, and products to secure funding and Lead Partner status	Dec 2014 to July 2015
DecManage applications and funding for Phase 1 projects and Community Engagement and promote the GISI. Repeat for Phase 2 projects	July 2015 to June 2023
Review project and close	June 2023 to Dec 2023

Table 2.1 Main stages of the GISI

3. Aims and Objectives

The specific aims of the Knowledge Exchange in September 2018 event were to:

◉ Host a GISI stakeholder event at a venue in the Central Belt.

◉ Aim the event at organizations with GI funding, staff from other ERDF Strategic Interventions in Scotland, Scottish green infrastructure network partners, and organizations that are potential applicants in future funding rounds if Phase 2 does happen.

◉ Have an event that is relevant and interesting enough to attract capacity attendance.

◉ Ensure that NatureScot’s profile is prominent at the event and in the communications surrounding it.

◉ Visit one or both sites from Round 1 that are making progress on the ground, or another green infrastructure project.

The event was part of NatureScot’s Sharing Good Practice series and needed to be within the set budget of £2,000.

The long-term goals were to promote more collaborative working or knowledge sharing among actors in the UK GI field, and to influence the Shared Prosperity Fund that was to replace EU Structural Funds post- Brexit.

The benefits resulting from the event will be that the network of organizations delivering and managing green infrastructure will be strengthened. Green infrastructure will have increased further in prominence, as an important part of modern urban planning and management.

4. Approach

A Sharing Good Practice (SGP) event is an opportunity to apply the PRINCE2 principle ‘Learning from Experience’ since projects with grants have valuable knowledge and experience that can help other potential applicants. The presentations at events are valuable, but just as important are the informal networking opportunities, and, ideally, on- site discussions during site visits.

The involvement of speakers with high profiles in the GI field, such as our CEO and staff from the ERDF Directorate that approve our funding, indicated that the success of the event could not be left to chance. During a period of austerity, attendees needed to be sure their time would be worthwhile. Specifying the requirements was one of the first steps:

◉ Each project should be given the chance to present to the audience.

◉ There must be two speakers (keynote and summing up) with UK prominence in the GI field.

◉ The participants should be welcomed to the event by either the Chair or CEO of NatureScot.

◉ The programme needs to have visits to projects.

◉ Sustainable travel must be a reasonable option.

◉ Publicity must credit NatureScot, GI, ERDF and partner organizations.

◉ Catering companies must source food locally when possible.

◉ Any organization involved will expect to see their project credited appropriately.

◉ People attending will provide feedback.

◉ People attending will have real opportunities to share their experience and learn from others attending.

4.1 Description of Planning process

The Sharing Good Practice (SGP) had an established process in place which we used the PRINCE2 method for. After the Knowledge Exchange was accepted, as part of the programme, two members of the SGP team were assigned as contacts, one of whom sat on the project executive as a senior supplier. The second person helped with most of the administrative tasks.

The project board included:

◉ Head of GI Fund team in NatureScot: project executive

◉ Manager of Sharing Good Practice team: senior supplier

◉ Head of Strategy at Central Scotland Green Network Trust: senior supplier

◉ Key contact from one of the Glasgow projects: senior user

◉ Project & Funding Officer: project manager.

Tasks	Breakdown of tasks
Planning	Organize the programme Organize catering Source the venue Organize speakers, workshop leaders, and facilitators Review dates to improve attendance, visit potential venues.
Pre-event	Publicity and promotion Practical communications for the event Draft in support from other parts of NatureScot Organize any materials needed for workshops, specification, and management of facilitator contract.
On the day	Ensure that the equipment is in place Greet attendees Record the event Risk assessment for any site visits Draft tweets and decide on a hashtag search for the event.
Administrative	Upload the presentations to the website Organize expenses payment and accommodation for speakers if needed Information system security checks for viruses in presentations Transport and subsistence (T&S) for speakers and workshop leaders Book coach transport.
Project management	Produce the project brief Complete the business case (online database form) Maintain the daily log Assemble the project initiation documentation (PID) Manage the budget for the project Manage the timeline Deal with risks and issues arising Record lessons to be learned Write the closure report.

Table 4.1 Breakdown of tasks

As an organization, we have existing tools to record and plan details of a project. Existing templates from Sharing Good Practice include: a planning timetable, tested programme timings, event checklist, and expenses forms. There is also a task list template available within NatureScot. In addition, we used the PRINCE2 Handbook to refer to best practice methods.

5. Challenges

We faced a few challenges during the lifecycle of the project. Some of these were minor, handled in passing, and possibly unique to this project. Others are possible issues for future events and were included in the lessons report. The venue change and cost increase triggered a management by exception event and was escalated to the project executive. Once again, the PRINCE2 method facilitated solutions.

Challenge	Solution
The original venue withdrew from the contract three months before the event, and a few days before we were due to distribute the flyers about how to get to the event, etc.	The information from the original venue search was still available, meaning a replacement was quickly found.
A TV news programme wanted to interview key personnel during the day, and with very little notice. The communications person had not been given clear boundaries	The team was briefed, so the project manager could advise on the interview without too much disruption. The Head of GI was able to do the interview.
The air conditioning was noisy and needed to be switched off by one of the venue team.	Identifying team members to deal with unforeseen problems on the day was a good idea.
A field visit leader was ill on the day.	A community member willingly stepped in on the day as a replacement because the project had high community buy-in.
The change in venue resulted in an increase of £600 to the overall budget.	The project risk thresholds resulted in the increased cost being promptly handled via the appropriate route, which gave greater confidence to the decision-maker. The previous recording of venues as a saved project document made deciding a replacement faster.

Table 5.1 Challenges and solutions

6. Successes

The event featured on the regional TV news, which exceeded expectations. Organizations that were interested in applying for Phase 2 of funding attended and were inspired to apply. The event enabled networking that led to better quality applications. The GISI is agreeing contracts with Phase 2 projects, some of which may be showcased at the UN Climate Conference in Glasgow in November 2021.

Existing projects realized that they were part of a larger trend, which is likely to continue well beyond the lifetime of the GISI. The community food growing projects were inspired to increase efforts toward a Glasgow-wide network of community food organizations.

Taking a risk by including a facilitated session on the performance of the GI Team provided constructive feedback. Recommendations were included in NatureScot’s response to the Scottish Government’s consultation on the Shared Prosperity Fund, the replacement for European Structural Funds. The facilitated session also made explicit how the GI Team had improved by understanding that change is very common in project management, and endorsed our problem solving and project management focus.

The most serious challenge to the project was the booked venue withdrawing its availability, because of change to its charitable objectives. The clear definitions of project organization and management by exception in the PRINCE2 manual expressed that I did not have to make decisions alone. We had a strong ‘focus on products’, which was crucial when the original venue cancelled. The product description for the venue and recording of results from the initial search made choosing a replacement simpler and faster. It is possible that without these two documents, the event would have been cancelled.

The lessons report has led to changes in how projects that may attract media attention interact with our communications team. The communications personnel are giving clearer boundaries on what to expect on the day, and ways of further delegating tasks on the day allows the project manager to take part in interviews more flexibly.

We were in the right position to be able to realize the benefits of the project outcome:

◉ The attendees are better connected, resulting in a network of community food growing projects.

◉ The benefits were as described in the project brief and business case in the Sharing Good Practice database, but the publicity exceeded expectations.

◉ The biggest contributor to success was the project brief (derived from AXELOS) in setting limits on the scope of the project, emphasizing the importance of learning from previous projects, and recording results.

◉ We had thought to organize a similar event for the Community Engagement projects. However, a review of the lessons report concluded that the potential risk regarding management of grant claims was too great to organize, without the support of the SGP team, which had been abandoned.

Source: axelos.com

Continue reading

Agile Project Management: not just for software & IT projects

Interest in and demand for Agile approaches for an increasingly wide range of projects and initiatives has never been higher.

Agile is a key trend. Interest in and demand for Agile approaches for an increasingly wide range of projects and initiatives has never been higher.

However there is a myth commonly attributed to Agile which continues to persist, after much discussion and debate, that often discourages individuals and organisations from even considering, let alone adopting, Agile Project Management. The myth says that Agile is only suitable for software and IT development projects.

In some ways it’s understandable that this misconception exists; after all, the whole concept of Agile was born in the IT and software development arena.

However, it’s simply not true, and it’s a myth that needs busting once and for all.

The AgilePM® approach – based on DSDM Consortium’s Agile Project Framework – has been designed to be industry agnostic, making it applicable for a wide range of projects and change initiatives, ranging from marketing and business development to restructurings and transformations.

AgilePM sets out a step-by-step guide to considering the feasibility of the work and suggests breaking the work into small but independently valuable components. It encourages their early implementation to generate funds to pay for further work.

Each of these elements makes AgilePM a sensible approach to launching anything new. After all, IT hardware and software are just examples of new products and services. AgilePM is not a set of instructions for technical work; it guides how any new product or service, or any refresh of existing products or services, can be launched.

A new marketing campaign, a new type of flooring, transferring a call centre from offshore to onshore can all be easily managed using AgilePM.

AgilePM helps to establish the feasibility of the new idea through the completion of a few well thought out documents which push those involved to outline the problems they are trying to solve or the capabilities they want to create.

It keeps options open by ensuring these questions are about what the future needs to be and not how it needs to be created. AgilePM establishes both what will exist in the future and the benefits that this will realise by describing very high level stories about what the project will lead to.

The recognition that specialists and experts can debate how best to achieve this only when the expected benefits have been estimated and agreed by more commercial minds is a great way to stop ‘vanity’ projects, i.e. creating new things for the excitement of creating new things. This protects capital from being sunk into things that will never pay back what was spent on them.

Building confidence in project management

Breaking work into independently valuable component parts delivers value very early in the life of the project. It is thanks to AgilePM that this practice is spreading, which reduces project risk and builds confidence in project management. It allows sponsors to get early evidence about the take up rate of their products or services.

We no longer spend all the money delivering all of the requirements before finding out if our ideas are as exciting to our customers as we thought they were going to be. We find out early if our assumptions were right, with money left in the budget to fix the things that don’t work.

If we are right, then early customer take up generates revenue to pay for further work and creates an atmosphere of success which is very exciting to be a part of.

The AgilePM guidance, training and certification scheme was developed by APMG International and DSDM Consortium.

Based on DSDM’s Agile Project Framework, the guidance offers a robust, practical and repeatable methodology for all types of projects. It achieves an ideal balance between the standards, rigour and controls required for effective project management, and the fast-pace, change and empowerment provided by Agile.

Source: apmg-international.com

Continue reading

Difference between Scrum and Six Sigma

1. Scrum:

Scrum is a lightweight framework for agile development. It is subset of Agile Software development process which is nothing but an iterative and incremental software development technology.

Scrum can be defined as an assembling of peoples and that represents a teamwork. A group of ten or less than ten peoples in which they have specific skills to perform their own task in a particular era. Scrum was introduced to develop, deliver and for satisfying the products in a multiplex habitat.

The team of scrum consists of a product owner, a scrum Master and the developers. It mainly focuses on the product and other roles as well.

1. Product Owner : Product owner represents the product’s stakeholder and it manages the requirement of the customer, also focuses on the productivity and betterment of business. This is the most important role which handles both the business sides as well as the developer’s side in the scrum team.

2. Developers : Developers plays a vital role here; they manage all the technical part for growth of the business. They also convey to the researchers, architects, designers, data specialist, analysts, engineers, programmer, for developing for developing or improvement of the product.

3. Scrum Master : Scrum master is responsible for removing the obstacles during the production or delivering. It also ensures that the scrum framework is obeying the methodologies of business or not and also in the growth of production. Scrum mainly helps the product owner to keep the backlog of the product, well-being of the business.

Workflow of Scrum :

In scrum workflow, it requires several steps those are:

1. Sprint Planning : In this method the product owner and the developers discussed together that which product backlog items should be given to the sprint. This sprint planning focuses on the correct executing and removing error to get a sprint goal and backlog.

2. Daily Scrum : Daily scrum given the overview of sprint goal. The developers with lack of their time they can check quickly and easily, assess the program, activity plans for the next 24 hour. The daily Scrum is limited for only 15 minutes.

3. Sprint Review : This process initiated at the end of the sprint. It authorizes the scrum team, the occasion to present the recent increment done to the stakeholders. It checks the improvement and the work process of the sprint.

4. Sprint Retrospective : This is the final step in sprint. This method ensures that what change could occur in sprint for the Improvement. This process resolves by collaborating all the members such as the product owner, scrum master, the developers, and the entire scrum teams for the betterment and progress of the business.

2. Six Sigma :

Six sigma it is a set of approach and which provide tools for processing and improvement. Six sigma was introduced by an American Engineer named as “Bill Smith” in the year 1986, when Bill Smith was working at Motorola company.

The term six sigma has been derived from statistical method. This mainly focuses on achieving profit and financial status. Six sigma is highly recommended for business growth and increment of profits as well. Based on statistical method we can easily detect the error in the system and also the cause of decrement in the business.

Six sigma always tries to succeed with its dedications and great efforts. It requires whole commitment with the entire organization and keeps everything in a detailed way so that it helps to understand quickly all the strategies. Abolishing dissimilarities, it saves our money and also reduces the faults.

Some of the most used tools for measuring and analyzing the process such as; Control Charts, 5 Whys, Root Cause Analysis, CTQ tree, Statistical Process Control, Process Mapping etc.

Workflow of Six Sigma :

The methodology of six sigma is based on two principles DMAIC and DMADV.

1. DMAIC :

DMAIC is derived from various words and having their specific meanings.

1. D: D stands for defining the customers requirement and project goals.

2. M: Measures the key point on the recent process going on.

3. A: Analyze the data. It analyzes data from the existing one for their benefits.

4. I: Improve processes. Examine and analyze for the progress.

5. C: Control future executions for the accurate outputs so that errors doesn’t comes again.

2. DMADV :

DMADV is also derived from various words.

1. D: Defines company and customer needs.

2. M: Measures CTQs (Characteristics that are critical to quality). It measures the product ability for growth and production and damages.

3. A: Analyze data from our computation.

4. D: Design the new method based on the preceding move.

5. V: Verify the pattern by a pilot run, applicating the new method and provide it to the owner.

Difference between Six sigma and Scrum :

Six Sigma	Scrum
Six sigma focuses on the method of controlling and similarities through reducing of errors and disparity.	Scrum is based on Agile program management process which focuses to control the software and product development by repetitive progress methods.
It is based on DMAIC and DMADV principle.	It is based on DMAIC and DMADV principle. It is based on Agile principle.
It requires highly changes on the documentation and good strategy.	It only requires changes on the teammate’s interaction and customer partnership.
There is no need of teammates	There is need of good teammates for guidance.
In six sigma there is no need to verify their works to such other departments.	In scrum the process is considered and verified by various departments.
It is ideal for companies working on large scale projects where the requirements and functions/processes are clearly declared.	It is ideal for agile companies which work on projects with changing requirements.
Six sigma improves processes by eliminating waste and variations.	Scrum breaks down the project into short sprints.

Source: geeksforgeeks.org

Continue reading

ITIL 4 and Digital Transformation White Paper

This white paper considers the inseparability of service management and digital transformation. It also examines how ITIL 4 puts services at the heart of the discussion and reflects the need for new ways of working to accommodate broader technological shifts and other management approaches.

Introduction

The term ‘digital transformation’ is widely used by business and technology leaders, but it is worth pausing to reflect on what it really means, how it emerged and why it is important. This paper will use the fictionalized example of a mobile banking app to demonstrate the concepts of digital transformation. The basic concept of digital transformation is that several significant technological events radically changed the way all enterprises work. Some of these created secondary events, which compounded the transformative power of this convergence of events. The list below is not exhaustive, but it serves to illustrate related advances that are relevant under this broad topic1:

• The availability of cheap and abundant computer power (Moore’s Law2)
• The availability of cheap and abundant storage space (Kryder’s Law3)
• Ubiquitous network connectivity (Gilder’s Law4)
• The explosion of internet-connected devices (Metcalfe’s Law5)
• Precise geographic location identification
• Data analytics, machine intelligence and machine-to-machine interactions
• Real-time feedback via social media.

The combined effect of these advances enabled representation in a machine-readable and actionable format of every document, image, video, sound, transaction, and measurement (typically referred to as digitization). This, in turn, disrupted entire industries with new business models and value-creating opportunities. ‘The business’ and ‘the technology’ became inseparable (often referred to as digitalization).

The advances described above created the conditions to catalyse the growth of other technology-related ideas, such as agile IT, rapid application development, Internet of Things (IoT) and software defined infrastructure. This fuelled a virtuous cycle, the consequences of which can be summarized as:

• The time and cost needed to prototype, build and run technology-powered services has significantly reduced, lowering the entry barriers for new competitive threats and opportunities.
• The cost for customers to change service providers has significantly reduced, which has lowered the barriers for change, therefore making markets more ‘liquid’ and enabling significant shifts in market share.
• The ability of organizations to reach, understand, influence and adapt to changes in customer behaviour has significantly increased, therefore improving the ability to create ‘mass personalization’ experiences through technology-powered services.
• The popularity of social media and the reduced cost of switching has made enterprises susceptible to real-time customer sentiment. Every type of enterprise is subject to an unprecedented level of threats, expectations and opportunities. Competitive forces are accelerating the innovation which is required to improve the way people work and live, changing the dynamics of local and global economies in the process.

For example:

• GE is providing field technicians with cutting-edge augmented reality glasses, which allow remote experts to see exactly what the technicians see as they repair wind turbines. It also provides the workers with hands-free access to information.6
• The Chinese education firm Liulishuo is changing education by introducing a sophisticated English teacher powered by artificial intelligence (AI) that delivers personalized, adaptive learning to millions of people.6
• Thomson Reuters has developed an algorithm that uses streams of real-time data from Twitter to help journalists classify, source, fact-check, and debunk rumours faster than ever before.6 This is a response to the critical need for accurate information which feeds the 24-hour news cycle.
• Amazon’s Echo device is managing customers’ shopping needs and the daily demands of busy lives. Amazon is now so integrated into day-to-day lives that new apartment complexes are designing dedicated Amazon Lockers for their buildings. People now trust the company with physical access to their homes, letting couriers make deliveries via Amazon Key and its smart-lock system.6
• Siemens offers its MindSphere operating system for IoT manufacturing devices to anyone, and as a result is cementing itself as an integral part of the new IoT universe.6
• Guatemalan shoe store Meat Pack pinched customers from competitors through a mobile app called Hijack. When potential customers entered a rival’s store, they were detected using the app and offered a promotion at Meat Pack. A discount countdown began, starting at 99 percent and ticking down by 1 percent every second until the consumer entered the Meat Pack store. When a discount was redeemed, the person’s Facebook status automatically changed to inform the world.7
• Netflix tracks how customers interact with on-demand film downloads to improve its recommendations engine. It looks at metrics such as when customers pause the movie and what scenes they watch again. Amazon Video cut its celebrity interview section of The Grand Tour after its data showed that most of the international audience skipped this section in Season 1 and 2.7
• Knewton incorporates the ability to track specific data about how students use its software to continuously improve the quality and effectiveness of its online class materials. It tracks how long it takes students to complete an assignment and their ultimate score. It also tracks their keystrokes, how long it takes them to answer individual questions, and if they stop in the middle of an assignment or question.7
• Catalina, a global marketing company, is using consumers’ profiles and in-store location, determined by the product QR codes they scan to generate offers as they shop for groceries.7
• Airbnb disrupted an entire industry, moving from initial idea to product in less than eleven months. It hyper-scaled to ten million bookings in less than 56 months.8
• Estonia became the first nation to hold legally binding general elections using the internet. It held a pilot project for the municipal elections in 2005, parliamentary elections in 2007, and parliamentary elections through mobile phones in 2011.9

Services and their ‘digital characteristics’

Imagine you were asked to build a new mobile banking service for Bank X. How would you define and segment the customers and other stakeholders of the service? How would you know what outcomes they were trying to achieve? And how would you define the components of value that really matter?

ITIL® 4 defines service as follows:

A service is a means of enabling value co-creation by facilitating outcomes that customers want to achieve, without the customer having to manage specific costs and risks.

The examples above neatly illustrate the importance of the definition of a service. In each case the relationship between customers (or stakeholders), value and outcomes is clear.

What is not always clear is how these things are managed as distinct services, or the role of the service provider in owning the associated costs and risks. When looking at an existing service, it can be difficult to imagine the mindset of the service provider when they first envisioned the service.

As we start to think about the role of the service provider, it is worth considering some of the key characteristics of technology-powered services that evolved from the virtuous cycle of digital transformation.

• Speed-to-market: These services have a quick transition from initial idea to reality. This requires much closer collaboration between teams from ‘the business’ and ‘tech’. Active involvement from those that really understand the customers, their desired outcomes, and what they value, is critical for success.
• Modular: The services are designed based on modular, loosely-coupled components, often focusing on a ‘minimum viable service’ that can quickly benefit from real-world feedback. This architectural style has the added advantage of allowing incremental changes in small batch-sizes, which both reduces the risk of change and increases change velocity. As with the characteristic above, this also requires close ongoing engagement at the business-technology interface.
• Fail or scale: The service leverages the low barriers of entry that come from a digital environment. Experimentation is cheap, rapid scaling is possible and failure is an option. Failure could mean change, and this sometimes presents a cultural challenge in organizations where the appetite for risk is historically low. 
• Cloud economics: The economics of these services are driven by OpEx and variable costs, rather than CapEx and fixed costs. This change in economic approach can often provide the catalyst for investment, but also presents challenges because the costs of using cloud platforms are consumption-based and may be unpredictable.
• Unknown unknowns: Given the pace of change it is important to recognize from the outset that there are some things we just don’t know. Service owners consciously seek feedback from customers and build adaptive systems that allow the service to incrementally evolve. This can be daunting because it involves consciously seeking feedback and asking customers and other stakeholders what they really think.
• Data-driven insights: This type of service leverages an individual’s data for mass personalization, and the entire data set for hidden insights. Not only does this require careful attention to navigate the challenges of information security, it also means that we need to become familiar with manipulating, processing and drawing insights from huge volumes of data.
• Automate to reduce toil: These services leverage automation wherever possible to allow for rapid change, predictable quality and the elimination of low-value human effort. This means that we need to culturally accept and embrace technology and automation and recognize our value. Often the best time to embed this mindset is at the start of service development activities, when technical debt is at its lowest and enthusiasm is at its highest.
• Improve services, not IT: The success of each service is reliant on empowered service teams that are free to be adaptive within certain boundaries. Traditional, top-down leadership, based on functions and rigidly prescribed processes, reduces change velocity and stifles innovation. Leaders should refocus their efforts on setting appropriate boundaries, developing service teams with a broad range of skills, and removing all unnecessary blockers to adaptive and incremental improvements. Service teams should be trusted and empowered to make the right decisions based on their in-depth knowledge, rather than a one-size-fits-all approach to the governance of functions or processes.

Service management: thinking differently

Returning to our example of the creation of a new mobile banking service, we start to think about our responsibilities as a service provider. Certain characteristics of the service lead us toward different ways of funding, architecting, ‘developing’, ‘operating’ and ‘managing’ the service.

The below examples of ‘thinking differently’ are driven by the context and characteristics of the service in question. A different service with different context and characteristics might require other forms of adaption. For example, a service with brittle architectures, high technical debt and limited need for regular enhancements may struggle to seize the benefits of digitalization. In fact, the service management mantra of adopt and adapt has never been more relevant than in situations where there is an abundance of choices. When developing our mobile banking app for Bank X we will plan for the following:

• Speed-to-market is important, with an acceptance that a ‘minimum viable service’ will be launched quickly to lay the foundations for rapid, incremental enhancements.
• The team will apply design thinking techniques and seek out skills in user experience (UX)/customer experience (CX). This will ensure good understanding of the customers’ expectations and desired service outcomes. A lot of focus will be placed on the bank’s external customers, but the design workshops will also include representatives from other key stakeholder groups to ensure that compliance, security, reporting and other dimensions of the service have been considered.
• A feature roadmap will be defined and prioritized to deliver the sufficient minimum viable service. This will include enrolling in the service, checking account balances and recent transactions, intra-account transfers, payments to others and ATM and branch locations. The features and functionality to deposit cheques using the smartphone’s camera, create and amend standing orders and direct debits, and block or unblock a card will be recorded on the service backlog but deferred to future releases.
• The service will require a loosely-coupled architecture, based on small blocks of code (microservices) and APIs, to allow for these rapid, incremental enhancements.
• A few service architectures will be proposed and assessed against the key dimensions of cost, performance, speed and risk. The team will settle on coding the application in Python and leveraging simple infrastructure-as-a-service capabilities. Furthermore, a rigorous information security assessment will be performed to gain approval for utilizing Public Cloud Provider X.
• As different architectures will be assessed, items may be added to the service backlog. For example, a simple approach to data back-up and archival may be agreed to balance speed and risk, but the team may then decide that there are other approaches to optimize for cost and performance after the minimum viable service has been launched. These approaches would then be reviewed and prioritized along with the roadmap of features and functionality as part of a holistic service backlog to create an appropriate balance between cost, performance, speed and risk.
• While the rest of the IT organization is designed around the traditional boundaries of applications, infrastructure, development, operations and security, the service team will be established as a separate entity with all the necessary skills required to manage the end-to-end service. A service owner will be appointed from IT with responsibility for facilitating the outcomes that stakeholders want to achieve from the service, whilst owning the specific costs and risks associated to it.
• A representative from the bank’s retail business unit will also be appointed to own the ‘voice of the customer’, to secure funding for the evolution of the service and make decisions on behalf of the business. Given the agreed approach of ‘start small, scale-fast’, this business representative will meet regularly with the IT service team to help steer efforts.
• During the initial development of the service, the service team may decide that they would incorporate continuous integration and continuous delivery (CI/CD) pipelines, highly-automated testing and blue-green deployments to maximize change velocity, minimize the risk of changes and reduce the impact of service failures.
• The application developers will quickly produce working code, along with the mechanisms to evolve it at speed and with increased quality. Meanwhile, the platform engineers will spend time understanding the key metrics of success (sometimes referred to as service level objectives) and defining appropriate error budgets to act as a throttle between the desire for change and the desire for stability. Furthermore, platform engineers will leverage centralized cloud platform management capabilities to ensure corporate standards are embedded, platform capabilities can be instantiated through automation, cloud-consumption costs are fully transparent and the ‘toil’ of repeatable, manual activities is automated where possible.
• Eventually, all stakeholder groups will agree the minimum viable service is ready for launch. The marketing campaign will be based on a ‘soft launch’ in a single country and v.1 of the new mobile banking service will be launched as a ‘blue deployment’, with feature flags set to control the initial roll-out.
• Once initial customer feedback is positive, the uptake of the mobile banking service may quickly exceed expectations. The transparency of cloud-consumption costs might show that demand is high and indicate that there are some parentless elastic IP addresses associated with the service that are incurring costs. The elastic IP addresses will be ‘stopped’ to optimize for cost.
• The service team will quickly move to reviewing and prioritizing items on the service improvement backlog and decide when to introduce new features into the next version whilst making operational changes to the underlying platform to improve monitoring.
• The CI/CD pipeline and automated testing established for v.1 will mean that the service team can quickly build and test the next version of the code. And the platform engineers will have new security standards so that the platform capabilities are instantiated through automation. Within a short time, version 2 of the Mobile Banking Service may be launched as a ‘green deployment’, using the same feature flags to control the roll-out.
• If monitoring the data suggests that the service is not performing adequately and highlights a need to roll-back to the ‘blue deployment’, the team will identify how to resolve the issues and quickly have a new version for the ‘green deployment’. Furthermore, the team may identify and introduce new automated testing to ensure repeat situations are caught before launch and new auto-scaling rules so that similar situations don’t impact the customer experience.
• The service team will continually identify, assess and prioritize opportunities to improve, evolving the service based on nearer-term business needs, rather than commitment to a fixed, multi-year plan.

Inseparability of service management and digital transformation

It is important to note that our approach to funding, architecting, developing, operating and managing the fictitious mobile banking service is not meant to be comprehensive. It simply aims to articulate the interrelated nature of many of the ideas often associated with digital transformation and ‘modern’ IT management. Although all organizations should consider how they can benefit from the technological advances associated with digital transformation, they will also need to master different IT management techniques.

Trying to break down the complexity of IT management is not a trivial task and the traditional IT domains of applications, infrastructure, development or operations are counter-productive to creating agile environments that foster innovation. ITIL 4, the latest iteration in the world’s leading service management framework, is unique in that it puts services at the heart of the discussion and reflects the need for new ways of working to accommodate broader technological shifts and other management approaches. This framework recognizes that true value does not reside in IT processes, functions or digital transformation programmes, but in the uniqueness of each service. Rather than promoting a rigid, one-size-fits-all approach, it also provides guidance that can be adopted and adapted to the uniqueness of each service.

References

1 Jim Miller, Forbes (https://www.forbes.com/sites/jimmiller/2018/08/13/what-is-a-digital-transformation-and-why-should-you-care/) [Accessed 22nd February 2019]

2 https://en.wikipedia.org/wiki/Moore%27s_law [Accessed 22nd February 2019]

3 https://en.wikipedia.org/wiki/Mark_Kryder#Kryder’s_law_projection [Accessed 22nd February 2019]

4 https://www.netlingo.com/word/gilders-law.php [Accessed 22nd February 2019]

5 https://en.wikipedia.org/wiki/Metcalfe%27s_law [Accessed 22nd February 2019]

6 Accenture Technology Vision (2018) https://www.accenture.com/t00010101T000000Z w /gb- en/_acnmedia/Accenture/next-gen-7/tech-vision-2018/pdf/Accenture-TechVision-2018-Tech-Trends-Report. pdf#zoom=50 [Accessed 22nd February 2019]

7 Accenture Technology Vision (2013) https://www.accenture.com/us-en/_acnmedia/Accenture/ Conversion-Assets/Microsites/Documents8/Accenture-Technology-Vision-2013.pdf [Accessed 22nd February 2019]

8 https://en.wikipedia.org/wiki/Timeline_of_Airbnb [Accessed 22nd February 2019]

9 https://en.wikipedia.org/wiki/Electronic_voting_in_Estonia [Accessed 22nd February 2019]

Source: axelos.com

Continue reading

The Open Group Open Footprint™ Forum Global Event Highlights Blog

The Open Group Open Footprint™ Forum (OFP) held its first virtual event, June 23-24, 2021. It brought together experts from across the globe to introduce and demonstrate the work that has gone into the Forum since it launched in August 2020. Speakers, from a plethora of industry leading organizations such as Accenture, AWS, Deloitte, ERM, IBM, Infosys, Shell, WBCSD, and Wipro hosted sessions outlining the mission of the Open Footprint Forum, explanations of the Open Footprint Data Platform, as well as live demonstrations of the Platform to show its applicability to all industries.

The Open Group Open Footprint Forum was kicked off by Heidi Karlsson, Director, OFP at The Open Group and Johan Krebbers, VP IT Innovation and GM Emerging Digital Technologies for Shell. Both Heidi and Johan provided an overview and introduction to the Forum, it’s mission and the work that is already taking place. The aim is to create an industry standard (and Open Source-based) data platform where emissions data of each company can be saved using these same industry standards.

Open Footprint Deliverables

Sammy Lakshmanan, Global Managing Partner, Digital Services, ERM, & Co-Chair of the Open Footprint Forum provided a brief walkthrough of the key deliverables and projects currently underway within OFP. Sammy highlighted the OFP Data Platform as a consistent way of exchanging, processing, and storing emissions-related data, aligned with reporting standards and frameworks that enable data to be accessible.

Sammy also showed a template for organizations looking to apply the OFP solution, ranging from data entry, to reporting, to integration that was further explained in a later session.

The final deliverable of the OFP Platform is the user interface/reporting. To store, view, and report the emissions-related data, including those that are shared across boundaries. There was more to come on this in the live demonstration sessions later on.

In the last session before the break, Gommaar van Strien, Shell, took us through the Open Footprint Data Platform, its goals, platform development, and plans for the future. When outlining the benefits of the OFP Platform, Gommaar said “Emissions/Factors/Models are auditable, data is searchable, and exchange data is in a standard format.”

This session was concluded with a roadmap and plans for the future. It was clear to see a lot of work has been put into the Platform but there is still a lot more work to be done, especially within the next 9 months.

After the break, Anna Stanley, Manager at The World Business Council for Sustainable Development (WBCSD), showed us the objectives of the WBCSD and what can be the links between WBCSD and the Open Footprint Platform. Anna began discussing The Carbon Transparency Partnership. Greater value chain emissions transparency through the exchange of verified, product specific primary emissions data to unlock and enable multiple, high value use cases for industry players, regulators, and governing bodies.

To summarize Anna’s session, she ended by saying “We’ve been working with the Open Footprint Forum for a long time now, and I’m really pleased that it’s one of the first initiatives to join us in creating Scope 3 emissions transparency.”

Up next we had an interesting session from Sumouli Bhattacharjee, ERM. This session focused on Green House Gas (GHG) & Reporting. To quote Sumouli on the direction GHG reporting is heading, “What is a gamechanger is the pressure from customers and suppliers.”

During this session, Sumouli highlighted what OFP can do to assist in the reporting of Greenhouse Gases. The Open Footprint Forum has engaged with some of the biggest industrial, technology, and sustainability organizations to put together a template of solutions which can be adopted across industries, supply chain, locations, and standards. OFP is focusing on standardization and accessibility of sustainability data to create an open ecosystem for exchanging data between organizations and across supply chain. Samouli said “OFP is collaborating with standards and framework organizations to facilitate consistent disclosure across multiple standards.”

Wednesday’s session continued with Sourabh Roy, Digital Strategist, Infosys Limited, for his presentation on Open Footprint™ Reference Architecture, data entry, and reporting. Sourabh outlined the Reference Architecture principles. The Open Footprint Platform is based on open-source, vendor-neutral components (in-line with the principles of The Open Group). Open Footprint Architecture leverages OSDU™ Data Platform Architecture. Some of the key principles for the Reference Architecture are Open-Source, Interoperability, Scalability, and the need to be Cloud-native.

Sourabh later broke down the Open Footprint Data Platform Architecture.

After the final break of the day, Johan Krebbers, Shell lead us through the Open Footprint Platform Strategy. This included the high-level direction, targets for the Forum, as well as showing the roadmap and plans for the future. Johan mentioned the need for agility in the platform, “Our main concern is the flexibility of the data platform. We need to be ready.”

To round up the first day of the Open Footprint Event, Luca Venturini, Accenture had an interesting presentation on Developments in the Market of Greenhouse Gas and Related Activities. This presentation acted as a timeline showcasing the trends in ETS or carbon Tax Coverage in the last 30 years. Luca explained that the energy transition is a long-term structural change in the global energy system from fossil fuels to net-zero carbon. This multi-faceted problem is driving companies to target holistic emissions reduction – from core operations to indirect customer and supply chain impacts.

Day 2

The second day of The Open Footprint Event began with an interesting session on the developments in the market of Greenhouse Gas and related activities. The presentation from Jacques Buith & Femke Perlot-Hoogeveen, Deloitte Consulting, LLP showcased the journey to becoming sustainable and impact driven. “A purpose-driven route in line with the global goals will embed sustainability in the DNA of organizations.” Before rounding up their presentation, both speakers left us with something to think about. “We’re in the decade of action. We’ve done the exploring, we need to start doing sustainability now.”

Key highlights of the event were the sessions from Sonia Van Ballaert, Ph.D. IBM Global Client Director Shell and Lizz Dennett & Merlyn Gregory of Amazon Web Services (AWS). These sessions covered both IBM and AWS Open Footprint™ plans.

Sonia van Ballaert, IBM, ran us through the new OREN platform from IBM and Shell, and how OFP will underpin transparent GHG reporting. “When we talk about carbon footprint, the mining industry has a huge footprint and we need to tackle it.”

Lizz Dennett & Merlyn Gregory, AWS in their presentation mentioned that “Sustainability is really just a data problem at its core”. They demonstrated the keys to success for optimizing operations: 1) leadership buy-in 2) get sustainability and IT in the same conversations 3) select an achievable, measurable pilot 4) provide training & support 5) set deadlines.

After the break, speakers William Fox and Javier Espinoza, Data Gumbo, demonstrated the OFP calculation engine design. In this session they showcased various scenarios of interest, the implications of each scenario and the pros & cons. Having showed the calculation engine design, they then went on to show live demonstrations with engine examples and business rule examples.

Heidi Karlsson, The Open Group Open Footprint Forum Director showcased opportunities for new and existing members. Heidi highlighted the need for collaboration in the future and the benefits of being involved in OFP. From opportunities for leadership, to receiving contribution and recognition rewards, there are a number of ways anyone can get involved in the Forums activities.

Next up, a host of industry experts took us through the Open Footprint demo of reference implementation. The key takeaway from this session was the live demonstration of “A day in the life of… a bed”. Sammy Lakshmanan, ERM, Bhupinder Singh Chawla, Infosys & Geert-Willem Haasjes, IBM, took the audience through the footprint journey of a bed. From production to a report from a customer success manager. The speakers finished the demonstration with a view of what’s to come.

Open Footprint Platform and what is expected by various industries

After the live demonstration, Ravindra Balija, Wipro showed attendees a summary of standards in industries that have been looked at and how OFP can be applied to these industries. In this session Ravindra demonstrated the level of reporting within the airline industry, shipping and airports environment. Among the key takeaways we learned that there are no common standards for storing and managing emissions data. Something that the Open Footprint™ Forum aims to rectify.

Source: opengroup.org

Continue reading

Agile Enterprise Solution Architecture

Enterprise Architecture (EA) as an enterprise planning framework has its place and merits, yet it often falls short of real-world IT expectations. The traditional EA approach defines the to-be state architecture that may exist for a while but does not last long. In most cases, an enterprise architect starts from existing architecture and makes improvements. Such improvements are constantly needed as complex systems EA guides and expects are subject to constant changes. In practice, an enterprise architect is either engaged in strategic planning (including business modeling) or solution-oriented architecture. Most of the routine work of enterprise architects, in fact, involves crafting application or technical architecture. Therefore, what really matters in the IT world is an Enterprise Solution Architecture (ESA) that inter-mingles EA with Solution Architecture (SA) and provides holistic yet pragmatic modeling to enterprise information systems, along with an incremental and iterative approach for agility.

Agile Enterprise Solution Architecture mainly covers five areas: 1) enterprise capability (enterprise-wide organizational considerations of strategic planning, business context, and relevancy), 2) requirement/case scenario (business process and functionality required for enterprise IT systems), 3) architecture overview (including traceable business measurements, architecture patterns, and architectural metrics such as principle, risk, architecture decision, etc.), 4) IT functional service (relationship/interaction, granularity, etc.), and 5) IT infrastructure (operational aspect).

Within this architecture, all high-level statements (business initiative, process, and the like) need to be clearly mapped into ESA elements before they can become part of the architecture. Importantly, the IT service serves as a liaison between the enterprise blueprint and solution architecture. Its focus is on different levels of service interaction, service offer, and service system. At the functional level, for example, IT services can be categorized as interaction service, application logic service, data service and technical service.

Agile ESA helps clarify enterprise-level issues and key stakeholders’ major concerns (or the architecturally significant concerns) by forming critical architectural thinking blocks, especially those in between enterprise strategies and capabilities, business domains and applications, and applications and technologies. For this purpose, it:

◉ Maps inputs from all stakeholders including implicit requirements or objectives

◉ Introduces key architectural metrics to reach realistic architecture decisions

◉ Employs techniques for service abstraction, service interface, and service realization

◉ Incorporates an analysis process for architectural modeling assurance and governance

◉ Advocates just enough architecture and significant architecture of value streams

◉ Instills T-shaped IT expertise via a modeling framework to balance the enterprise capabilities and IT service modeling at the right level of abstraction and correlate between different architectural aspects (business and IT, application and technical, functional and operational, logical and physical)

As a modeling framework, Agile Enterprise Solution Architecture targets the following objectives:

1. Simplified: Eliminate unnecessary complexities in a traditional enterprise architecture, and simplify various architectures into a core model for easy learning and wider adoption

2. Panoramic: Take a holistic approach to trace back and forth key architectural elements (business, technical, and alike), and make enterprise architecture readily applicable and pragmatic

3. IT Service-oriented: Focus on enterprise capabilities and IT services (the primary elements), strike a proper balance between enterprise architecture’s strict definitions and solution architecture’s granular details, resulting in IT service architecture delivery (rather than traditional roadmap, business entity, product, or component)

4. Adaptable: Apply to various architectural styles (enterprise or solution, emergent or intentional, cloud-native or monolithic, software or system-scale, business or application) for ready customization and extension, and architect for changes to meet enterprise growth

Source: opengroup.org

Continue reading

How to Use Microservices: A Guide for Enterprise Architects

Many organizations have started to break up a portion of their monolith applications and systems, transitioning to sets of smaller, interconnected microservices.

A recent survey by TechRepublic, found that organizations who used microservices were reaping clear benefits: 69% were experiencing faster deployment of services, 61% had greater flexibility to respond to changing conditions, and 56% benefited more from rapidly scaling up new features into large applications.

But when are microservice architectures the best option? When can they offer the most value to an enterprise? And how do they fit in the enterprise architect’s toolbox?

The Benefits of Microservices

Consider a car production assembly line, where task specialization has been introduced to manufacture each part. Individual tasks become more efficient due to dedicated resources, operations, and labor. These newly generated efficiencies drive greater productivity and output, benefiting the overall process. 

Similarly, in microservices, or microservice architectures, separate modules are responsible for building and maintaining different components of the end-product. Individual units can be modified and scaled without disrupting the other parts. In contrast, implementing changes to a single, large “monolith” module, can be difficult to manage and can quickly become complicated.

Microservice vs. Monolith Architectures

The O’Reilly Microservices Adoption in 2020 report found that “77% of respondents have adopted microservices, with 92% experiencing success with microservices.” 

While the advantages of microservice architectures are plentiful, there are also tradeoffs to consider when comparing to monoliths.

In short, microservices still need to be “architected”:

◉ Communication between separate services is more complex. As large applications can contain dozens of services, managing the interactions between modules securely can add extra challenges.

◉ While microservices allow for different programming languages to be used, the deployment and service discovery process is more complicated. A broader knowledge is needed to understand an application’s full scope.

◉ More services equal more resources. For the car manufacturing example above, each task station requires individual tools, workers, and processes. Likewise, a single service may call for a dedicated database, server, and APIs.

How and when to Migrate a Monolith to a Microservices Architecture

When deciding if a microservice architecture is the right option, enterprise architects need to consider their organization’s goals and concerns.

As it’s uncommon for new architectures to be built from the ground up, a migration from one state to another is the most likely scenario. This transition begs the questions: What does the current architecture allow? What does it limit? What are we trying to achieve?  

Sam Newman, author of Building Microservices: Designing Fine-Grained Systems, suggests starting with Domain-driven design or DDD. This modeling exercise enables an organization to “figure out what is happening inside the monolith and to determine the units of work from a business-domain point of view”.

Considerations when Building a Microservice Architecture

Once an enterprise architecture practice has settled on migrating from one architecture to another, the team can ensure the process is heading in the right direction by:

◉ Determining the level of modelling detail;

◉ Deciding on the applied properties, and;

◉ Setting appropriate KPIs.

Microservices (Integration layer) dashboard in ABACUS

As different microservice platforms have different approaches to service classification, classifying an organization’s microservices should be a key priority.

One commonly used approach is to categorize services across the 3-layers of: Experiences, Processes and Systems. The diagram below illustrates this approach, using 3 layers of integration components for business services/events.

Microservices Modeling in ABACUS using an Extended metamodel for Integration Services in 3 layers: Experience, Process, and Systems

The Process of Mapping Microservices

It’s straightforward to model microservice architecture. The following 7 steps can help to inform your modeling process:

1. Adapt the metamodel to support microservices. ABACUS provides a number of architectural patterns which can be used to update your current framework for this purpose.

2. Populate the microservices portfolio to enhance the production architecture of the microservices layer. Use the data you have already uploaded or integrated with ABACUS.

3. Add properties and values to further develop the architecture

4. Create views such as Microservices Portfolio, Microservices Solution View, Microservices Dependency Views, etc.

Layered Microservices Modelling using Application Services and Application Interface in ABACUS

Microservices Modelling using “Publisher – Broker – Subscriber” Pattern in ABACUS

◉ Establish the relationship between microservices based on data flow and services orchestration.

◉ Design and implement analytics such as microservices cost, complexity, and availability.

◉ Develop a reporting dashboard and assess integration scenarios (see above example Microservices (Integration layer) dashboard).

Source: opengroup.org

Continue reading