For a governance process to be successful it is vital that everyone involved is clear on what is expected of them. An Estafet SOA Architect will work with you to document the terms-of-reference for your SOA Governance function including goals, principles, roles, limits to authority and dispute resolution process.
- SOA Governance Board Terms of Reference
- Outline transition plan
- Templates for Governance Board meetings
- Ensure Governance Board so ready for first meeting
- Establish roles and responsibilities
- Common process across cloud and on-premise projects
- SOA Governance function effective from first meeting
- In-flight projects can align with expectation
- Fluid transition to effective governance
- Support your hybrid cloud projects
- Short, time-boxed and inexpensive
£9500 per unit
|How the planning service works||
We use agile (Scrum) techniques to plan, deliver and report transparently on progress. This includes creation and management of a Product Backlog with story point estimation of tasks and a fixed release schedule. This allows the team to lay out the work in advance, establishing dependencies on other teams (e.g. from your own organisation) and deliver incremental and verifiable functionality. Experience has shown us that our experienced teams establish a good and consistent velocity (i.e. progress through these tasks) and so enable effective planning and consequent adherence to project timescales.
For each of our GCloud offerings, we have build up a prioritised and estimated backlog of tasks which describes a typical engagement. On day 1, we share this with you, make any minor adjustments where necessary, and can begin delivery immediately. Previous customers have found this to be an effective way to build confidence in the delivery and manage both their own and our consultants’ time.
|Planning service works with specific services||No|
|Training service provided||Yes|
|How the training service works||
Training is split into two elements: formal classroom learning in middleware products, for which we recommend the middleware vendor’s own training schemes, and collaborative knowledge transfer, which is a key activity for all our consultants on all engagements.
Classroom learning teaches your staff the technical elements of how to use middleware products and is a usually prerequisite to understanding best practice and the implementation itself. We will recommend the training you need based on role so that you have all the skills necessary to manage and improve the cloud implementation.
Knowledge transfer is both planned and opportunistic. The planned learning concerns configuration, processes and understanding what has been delivered. Opportunistic learning occurs when solving problems (from design choices to resolving live issues) and are worked on collaboratively with our staff and your own. The goal here is to develop critical thinking and approaches to problem solving which you can apply after we’ve gone.
|Training is tied to specific services||No|
Setup and migration
|Setup or migration service available||Yes|
|How the setup or migration service works||
There are three strands to our approach to cloud migration (from on-premise to cloud or between cloud services):
1. Understanding the current business functions and future needs;
2. designing for services, microservices and APIs; and
3. delivering flexible implementations that allow for later re-use and orchestration.
Our architecture specification supports each of these three strands to deliver solutions which consume open standards, are interoperable, promote re-use, are secure and targeted at cloud.
|Setup or migration service is for specific cloud services||No|
Quality assurance and performance testing
|Quality assurance and performance testing service||Yes|
|How the quality assurance and performance testing works||
Quality is never an accident, but the result of high intention and directed intelligence. It is vital to our company as it is to our customers.
Our vision is centred on the concept of small, self-managing, agile teams of technology experts. Teams actively manage their own quality by setting short-term, achievable goals; working to achieve those goals; and then setting themselves tougher goals. We include testers and peer review within our agile teams so that the ‘Definition of Done’ for a give Sprint includes a measure for assurance, not simply progress.
As a result, our customers benefit from increased agility - our designs and implementations are flexible and extensible - as well as shorter regression cycles and reduced time-to-market.
|Security testing service||No|
|Ongoing support service||Yes|
|Types of service supported||
|How the support service works||We do not host cloud services; however, we work with vendors who do, and these vendors (such as Amazon EC2) will provide all support for the platform. We provide 2nd and 3rd line support for both the software that has been delivered on the cloud platform: the custom configurations, the services, and the integrations. This can be delivered either on-site or remotely (usually through our near-shore office in Sofia). We can be flexible in this provision, and many customers seek to take on support of their own environments once the initial rollout is complete and the system settles down into business as usual.|
|Service constraints||We supply 2nd and 3rd line support both on-site the UK and remotely via our nearshore office in Sofia. Our experience is that customers tend to want 2nd line support to be on-site and 3rd line to be out of Sofia. We are flexible in this and want to find a way that works for you. We don't run our own ticketing system - customers invariably want to use their own ones - and will need access to your production systems to operate 2nd line support. We can obtain SC clearance for UK-based staff if required.|
|Email or online ticketing support||Email or online ticketing|
|Support response times||SLAs are negotiated according to customer need, the nature of the system, and the priority of the incident. Typical 2nd line SLAs for a priority 1 incident are to respond within 1 hour; update within 3 hours and resolve within a business day. This drops for low priority incidents so that, for example, a Priority 3 incident will be responded to within 3 business hours updated within 3 business days; and resolved within 5 business days. The SLA for the platform itself is usually higher than that for the business software, because resolving software bugs usually requires more investigation.|
|User can manage status and priority of support tickets||No|
|Phone support availability||9 to 5 (UK time), Monday to Friday|
|Web chat support||No|
We typically deliver on-site 2nd-line support and remote (nearshore) 3rd line support by a committed team of engineers who understand both the cloud platform and the software running on it.
Our rate card is attached; however, typical rates are £250pd for nearshore support and £750pd for UK support.
Technical account managers are available for larger customers (where a team of engineers is required). We are flexible and will listen to your needs before putting forward a pragmatic and cost-effective proposal.
|Supplier type||Reseller providing extra features and support|
|Organisation whose services are being resold||Red Hat provides the PaaS; we provide the implementation.|
|Staff security clearance||Other security clearance|
|Government security clearance||Up to Security Clearance (SC)|
|Price||£9500 per unit|
|Discount for educational organisations||No|
|Pricing document||View uploaded document|
|Service definition document||View uploaded document|
|Terms and conditions document||View uploaded document|