A web page detailing my more recent middleware IT projects managed at Capgemini starting with my augmentation into MuleSoft (a Salesforce company) followed by a 12-month project allocation in the Automotive Industry. mark whitfield
1) UK Utility, Accounting & Recruitment Industries (MuleSoft Middleware & Integration Projects – Anypoint Platform – 2018 to June 2019) :
From October 2018 to June 2019, augmented into MuleSoft (a Salesforce company) as a Delivery Manager managing a number of accounts across the UK, for the delivery of the Anypoint Platform. mark whitfield
The Anypoint Platform includes various components such as Anypoint Design Center, which allows API developers to design and build APIs; Anypoint Exchange, a library for API providers to share APIs, templates, and assets; and Anypoint Management Center, a centralized web interface to analyze, manage, and monitor APIs and integrations.
The Delivery Manager role is much like a Programme Manager role and typically links with the client’s Project /Programme Manager role to ensure that any project plans align to the MuleSoft Outcome Based Delivery (OBD) framework to achieve the agreed business outcomes. mark whitfield
The OBD framework provides a structured set of work streams, tasks and sub-tasks for the client to become fully enabled in an API-led project delivery as part of the business operating model. It also provides best practice guidance on the required business and IT culture modifications and governance to support the correct API ownership approach. The 3 OBD streams are; 1) Business Outcomes, 2) Technology Delivery and 3) Org Enablement. mark whitfield
DevOps (CI/CD) and the client’s internal support model are also a key focus of the OBD framework for completed API connectivity delivered to pre-prod and production platforms. This enables allocated support teams to become skilled in the correct triaging of service tickets and follow on troubleshooting against the software application(s), cloud provision of hardware components, Anypoint Platform and connected end-points, resulting in fast turnaround for agreed SLAs. mark whitfield
The OBD tasks can be client prioritized and assigned to Agile Sprints as part of a Product Backlog or lined up appropriately in a Waterfall project plan. The Delivery Manager tracks MuleSoft partner/resource effort, time, cost and client OBD RAIDs and status. The Delivery Manager also advises and works with the client’s Project Manager to help plan OBD tasks into an overall project plan to deliver the agreed set of API use cases.
As such, the main aim and end goal for the Delivery Manager is to enable the client to achieve a trusted C4E (Center for Enablement) to successfully deliver best approach builds for robust, future-proofed and reusable APIs and connectivity with the Anypoint Platform with the appropriate IT and business ownership and internal support operating model in place to manage and support those APIs. mark whitfield
With C4E, the client’s own IT and business resources become suitably trained and enlightened to carry out an effective API-led delivery approach across subsequent Anypoint projects with little or no MuleSoft SME support over time (the client becomes ‘Fully Enabled’). At this point, OBD and C4E becomes an intuitive, centrally documented, transparent and embedded part of the client’s operations (business and IT) to deliver APIs quickly and against a proven accessible blueprint that can be followed by newly on-boarded project resources. mark whitfield
Comprehensive training plus a training and on-boarding plan are very much a part of the OBD delivery framework focus. The plan allows new staff (business or IT) to quickly acquaint themselves with the client’s governance approach around OBD and if required, the Anypoint Platform technology.
As a typical team of 3, the MuleSoft Delivery Manager also works with a MuleSoft Senior Architect and Senior Consultant on-site to assist and enable client resources to design and build APIs against best practice approaches, guide in the required strategic architecture for the client’s API road-map, agree integration patterns and deployment models and ensure that Anypoint connected systems have the required capacity to support future demand. mark whitfield
For the Outcome Based Delivery (OBD), the main tasks summarized are;
Business Outcomes tasks are 1) Agree on Business Outcomes and KPIs, 2) Develop the Overall Success Plan and 3) Monitor and Manage;
Technology Delivery tasks are 1) Define Anypoint Platform Vision and Roadmap, 2) Design Anypoint Platform Architecture and Implementation Plan, 3) Deploy the Anypoint Platform, 4) Prioritize IT Projects and Quick Wins, 5) Staff and On-board the Project Teams, 6) Define Reference Architecture and 7) Launch Initial Projects and Quick Wins
Organisational Enablement tasks are 1) Assess Integration Capabilities, 2) Establish the C4E Operating Model, 3) Build and Publish Foundational Assets, 4) Evangelize the Center for Excellence – C4E, 5) On-board MuleSoft, 6) Determine the Internal Support Operating Model, 7) Staff, Train and Launch Team, 8) Publish Support Guidance and Self-Serve Materials, 9) Agree on Initial Roles, 10) Train the Initial Team(s), 11) Develop the Broader Training Plan and 12) Launch Experiential Learning Opportunities.
2) Automotive Industry (Capgemini Middleware Project – iFAB – 12 months) :
From Oct 2017 to Oct 2018, I was assigned as the Engagement Manager (EM) to manage 3 parallel Agile delivery projects at a large car manufacturing company with a client-side Product Owner assigned for the traditional Agile Scrum delivery model. The Capgemini EM is responsible for the project planning, control, organisation, stakeholder communication, aligning with current GDPR directives and status reporting against delivery of Capgemini services to the client along with project financial tracking and forecasts. The EM is also the first escalation point for the project team and the client.
This set of projects involved the rapid deployment of reusable public, partner and corporate APIs (for 3 Agile project deliveries) to aggregate data from client Systems of Records (SORs) via middleware on a Google Cloud hosted platform – iFAB (Information Fabric). mark whitfield
The first was a £430k Digital Readiness (DR) Capgemini middleware project to both performance test and then upgrade the product stacks (TIBCO (CIS) data virtualisation and WSO2 middleware) for a previously delivered, Google Cloud based ‘Information Fabric’ (iFAB) Enterprise Integration platform. This iFAB cloud platform allows for the rapid deployment of APIs to unlock the data in many back end, supplier hosted systems thus enabling new, digital applications. The architecture diagram below provides a simplified view.
As shown above, iFAB is a platform that provides reusable public, partner and corporate APIs that aggregate data from client Systems of Records (SORs). The platform contains API Management, Enterprise Services (Middleware; Cache, Broker, Enterprise Service Bus, Rules, Business Process Modelling, Complex Event Processing) and a corporate data model (hosted in a Data Virtualisation layer). It is underpinned by security, auto provisioning and operational monitoring capabilities. The iFAB platform(s) is provided as a managed service and accelerates the delivery of client business services.
The WSO2 middleware is a broad framework to develop, reuse, run and manage integrations. It’s architected around a common code base of fully open source integration technologies. Components can be used individually, or as a cohesive integration-agile platform. mark whitfield
The second £1m Agile project managed, Customer Portal (CP), delivered a number of new, asynchronous APIs to the middleware, iFAB layer to provide customers with both online personalised account access to their car service history and warranty data as well as enabling social media gateways and customer profile management.
The third £300k project managed introduced a further set of new APIs to the iFAB middleware to compliment those delivered by the CP project above. This delivery was to provide a first phase New Car On-Line Sales (NCOS) aspect to the firm’s on-line digital real estate. mark whitfield
Each of these 3 projects were successful deliveries and after a kick-off session, ran as Agile framework projects with all Scrum ceremonies enabled for both Capgemini and client stakeholder management with my EM responsibility for full project tracking, financial forecasting and reporting and linking with the client Product Owner. The prioritised Agile Product Backlog Items (PBIs) / Sprints and documentation were maintained in Atlassian Jira and Confluence respectively.
All projects were run out of the Capgemini Aston – Agile Delivery Centre (ADC) near the centre of Birmingham, with on-site client stakeholder engagement for the EM. Architectural guidance was provided by an assigned Senior Solution Architect for iFAB to ensure adherence to middleware and Google Cloud best practices and approach. The Solution Architect also provided coaching and mentoring to technical staff brought into the Scrum team as well as help the EM with the remediation of technical issues with the client. mark whitfield
For all the above projects, all of the new APIs have some TIBCO (CIS) involvement. Four of the APIs developed involved updating data in the SV-CRM product (Single View, CRM by Keytree). One API involved retrieving data from a third party, cloud-based web-service (InControl) – this was done from the WSO2 ESB middleware rather than through TIBCO.
The Customer Portal (CP) Gigya Event API is a highly complex integration involving the WSO2 ESB middleware and has dependencies on some of the other Customer Portal APIs. The Gigya API integration offers customer identity management for managing profiles, preference, opt-in and consent settings.
3) Aerospace & Defence (Capgemini) Integrating Portals/ Platforms –
SCV / Salesforce – Single Customer View Project :
In January 2017, I was assigned to a client-side, portfolio management role (SPL – Senior Project Lead), tracking project budgets and corresponding supplier deliverables for a number of airport projects including the Single Customer View (SCV) Salesforce project. This project brought together user related but unconnected data from disparate airport, digital portals and platforms into a single data warehouse to provide a comprehensive view of activity/usage for individual customers across all airport offerings.
SCV Project Summary
Airport customer expectations and behaviours had undergone a paradigm shift in recent years. Customers expected businesses to engage with them as an individual, know how they have been interacting with the brand irrespective of multiple touch points and also give them the choice to engage on the channel of their choice at the time they want.
The right message, at the right time, through the right channel, had become key to customer acquisition, engagement and retention through CRM software, enhancing customer satisfaction, building brand loyalty and ultimately driving commercial revenue. mark whitfield
The airport has a great deal of data about customers, but previous to this new Salesforce project, that data existed in a wide variety of disparate silo’s and could not be shared and was never integrated as cloud and on-premise platforms had organically increased in numbers and had no ‘line of sight’ with other business functions.
This SCV project would bring matched customer data into a central repository using Salesforce, where it could then be analysed and shared across multiple channels to significantly improve the customer experience. This as well as provide the airport with stronger GDPR, tracking, management and auditing capability for registered users. An executive summary of the real-time architecture is shown below:
Background
The airport had an existing SCV application which had been managed since 2002 and had evolved over time to support the CRM communications programme. This had provided some tremendous successes, but the capability was limited to quite simple communications including newsletters and targeted offers. Data from the previous SCV was not shared across the airport estate, so information about a customer could not be available to agents in call centres and at the airport. Also, the previous SCV was used primarily to generate pre-scheduled outputs in an overnight batch mode and was largely non-reactive to real time activity at the airport. An opportunity existed to enhance the SCV with rich data from a number of additional sources. This would become the new Salesforce SCV project. mark whitfield
Moreover, the existing SVC also did not contain customer data for a number of touch-points and this limited the ability to have an holistic understanding of the airport’s relationship with customers. The data sources not contained in the previous SVC included;
- Contact Centre
- Social Interactions
- Personal Shoppers
- Parking Contact Centre
- Rail Contact Centre
By including these data sources in the new Salesforce SVC view, there were benefits to business processes in 3 major functions within the airport;
- Commercial – Improved customer experience (with Ops), increased revenue / margin / cost efficiency
- Operations – Greater predictability, more effective resource allocation, more proactive service recovery
- Insight – More data sources / better insight
Due to the real-time nature of some of these data sources (Social in particular) it was possible to react in real-time to customers, whether in response to customer service issues, or to provide them with a highly relevant offer that would improve their enjoyment of the airport experience. In addition, the Salesforce SCV project provided data to each channel that meant that agents could have a complete record of a customer’s history, so for example can see that a customer has had a number of poor experiences at the airport recently. The airport agents will also be able to respond to specific situations with tools that can improve the perceived customer experience, for example the ability to offer credit points under specific and formalised criteria.
As indicated above, there were a number of considerations which provided inputs into a 6 week period of detailed planning (Stage 0), outputs from which informed Stage 1 and included;
- The costs of enhancing SVC data from the 5 sources outlined above
- The use cases and business processes that will consume the data
- The business case
Project Timings
Target completion of the first implementation phase of SCV (Stage 1) was January 2017 as per the implementation plan delivered during Stage 0.
There were 2 subsequent phases of the SCV project (Stage 2 and 3) each of which were presented under separate cover to G3. These following phases would build on the capability delivered in Stage 1 and significantly extend the benefits but were not required to be delivered to realise the tangible benefits of Stage 1. Stage 1 could be seen as a foundational step on a journey to improve SCV, with the final stage being integration of airline data with all of the associated benefits that this stage would then bring.
Business Needs
The route to sustainable competitive advantage was to deliver a superior customer experience in every engagement with the customer. Whilst more informed customer service is the primary benefit of this successful project, the airport had also identified areas of revenue generation (increases advocacy, loyalty and conversion) and cost reduction.
The airport required a solution that enabled communication with customers in an informed and relevant way, enhancing customer satisfaction and building brand loyalty; a solution that integrated and analysed data from new sources like web, social and mobile and delivered communication on a variety of channels based on real-time triggers and/or offline insight e.g. push notifications on mobile when a customer enters a Terminal. mark whitfield
Project Scope
Given the range of data items that would be integrated into SCV, the plan was to adopt an Agile framework approach with a client Product Owner as for the traditional Agile model. Then with a series of 2-week sprints, delivering the integrated data capability using Salesforce and appropriate middleware product stacks, in phases from May 16 for 8 months. In parallel, revised SCV enabled business processes, operating model, business change and customer strategy would be developed to support deployment of SCV in channels. Thereafter the capability would be deployed incrementally, to leverage the platform through a road map driven by a CRM strategy and readiness/ maturity of other business solutions e.g. push notifications through an airport mobile app.
Senior Project Lead (SPL) Role
My assigned SPL role focussed on supplier management and tracking through 8 Gates with Gate 3 being the solution designs and costs for a Go/No-Go for continuing with software development. This client is steeped in heavy governance with a number of strict Gates for project delivery for which the SPL role monitors and tracks supplier delivery ensuring timelines are met and that airline’s money set aside after board agreement is not exceeded without prior agreement and good reason. The SPL role reports to the Business PM and the Programme Lead and updates stakeholders at various steering boards (supported typically by SPL authored PPT project packs summarising current position/ spend/ risk).
The SPL also has to submit financial spreadsheets monthly and provide project reports at regular intervals on project status, along with RAID logs. The SPL also overlooks PO, CR and SoW approval as part of project delivery amongst other duties.
4) Postal Services – (Capgemini – Business Integration Gateway Interface and Middleware / Script Migration project – 6 months) :
In May 2016, assigned as a PM on a successful £4.3M (100+ Capgemini staff) migration project to migrate interfaces between a legacy Enterprise Integration Platform (or Business Integration Gateway – BIG) within an old Data Centre (provider) to the strategic BIG in the new Data Centre (new provider). There were 1100+ interfaces in total, that integrate various internal applications and external trading customers. The majority of the integrations were through file transmission using UNIX shell scripts and about 150 interfaces process through IBM ESB middleware. The customer’s vision was to both migrate all interfaces and upgrade some of the outdated middleware to new product / to a stable version of the product before peak trading and the change freeze by October 2016 end.
A Business-Critical Task
At the beginning of the engagement, the exact scale of the migration was not really understood but was thought to run to around 700 interfaces. In fact, the number was actually closer to 1200. The team needed to migrate from the legacy BIG to the Strategic BIG platform (different service providers) and, at the same time, test and implement 50+ transformed GXS interfaces. mark whitfield
Adding to the project pressure, it was vital for the client that the migration be completed before the end of October 2016 (change freeze pre-Xmas) to avoid their peak trading period and the significant commercial cost of being on legacy BIG for several more months. With the engagement kicking off in April 2016, this gave the team a tight deadline of only six months to deliver. The architecture diagram below provides and executive summary of some of the transport and middleware components involved:
Innovative Delivery
The teams structured the migration by technology component (FTP Solutions, IBM DataPower Web Services Gateway middleware, and IBM Message Broker Enterprise Service Bus middleware).
This innovative mobilisation approach allowed each Component Stream to largely focus on its own delivery with some high level dependency management overlaid. This team strategy helped maintain a ‘fast feedback loop’ to quickly determine best approach for implementing the specific stream components, with teams set-up with the relevant expertise in each technology stack area. This also ensured adherence to architectural best practices and guidelines under the guidance of an assigned Senior Solution Architect. Each of the team leads also coordinated and planned deployment to pre-production environments and eventual assistance with the go-live production deployment.
The project was a shining (and Capgemini team award winning) example of collaboration with the client and other partners. A shared determination to complete the migration by the end of October led to risk-based testing and fast-tracking processes (e.g. change, firewalls, gating) to reduce each by several days per instance.
Working innovatively with the client, the team completed the migration before the end of October 2016. This also allowed good time for client mentoring and knowledge transfer of the newly configured Enterprise Integration Platform to enable client development, additional configuration and maintenance of the platform and its various scripts, middleware and transport components. mark whitfield
The Team
The team peaked at over 100 people at nine locations across the UK and India and included AD and AO in the UK, Testing in India, DCX and legacy IGATE.
Mark Whitfield 