A paradigm for aligning Development, Delivery, Infrastructure Setup & Management, and Operations in a seamless manner, with identity & security always at the forefront. Policy-based, automated, and with well-segregated but aligned responsibilities.
DevOps, an integrated approach for development and operations of software and services, and DevSecOps, adding a security angle, have been around for close to a decade. While DevOps became an established principle, combining agile software development and the subsequent operations, DevSecOps – despite being intensively discussed – is seldom implemented and enforced in practice.
This leads to a variety of challenges, such as:
- Security as an afterthought, leading to sub-optimal implementation of security and delaying the delivery of software
- Identity as an afterthought, leading to islands of identities instead of integrated identity, and identity-related risks such as weak authentication, but also bearing the risk of inadequate customer experience on the onboarding and access journey
- Violation of the requirements, such as in GDPR, to deliver privacy-by-design and security-by-design, as well as gaps in security-by-default, caused, e.g., by coding settings instead of relying on identity and security services
- Lack of consistent, stable Security API layers and Identity API layers that consume standardized services from Security Fabrics and Identity Fabrics, leading to extensive effort for continuous redevelopment and re-coding of security and identity instead of just consumption of standardized services
- Security-as-code as a misconception, meaning that developers are involved in coding security instead of utilizing APIs (Application Programming Interfaces) to consume security and identity services
- Infrastructure security is defined in code, which is error-prone, hard to manage and virtually impossible to incorporate in comprehensive Access Governance, and which requires developers to spend time on tasks that are not within their primary focus
- Lack of segregation of duties between development, infrastructure, operations, security, and identity
What Is SODAS
SODAS (Secure Operation & Development of Agile Services) is a concept that addresses these shortcomings and can be used as a foundation to achieve the benefits of:
- Fast, agile software development
- Efficient, automated infrastructure setup and software/service deployment
- Secure, efficient operations in multi-cloud, multi-hybrid environments
- Delivering secure software on time
- Consistently enforcing the principles of privacy-by-design, security-by-design, and security-by-default
A major principle within SODAS is to strengthen the skills of employees by focusing on these, instead of requiring, e.g., developers to deal with infrastructure specifics, or security experts coding security instead of just declaring policies. Segregation of skills and specialization help in evolving the workforce even in an age of a skills shortage. It also helps in having clearly-defined accountabilities and responsibilities, leading to a more efficient, but well integrated IT organization.
Fig. 1: The three pillars of the SODAS approach, spanning agile development, automated setup and management of infrastructure and operations, underpinned by consistent identity and security services.
The 3 Pillars of SODAS
SODAS consists of three pillars and a foundation, which is Security and Identity. It extends the DevOps and DevSecOps paradigm by requiring a closer integration with Infrastructure Management, specifically by adding Security and Identity in a manner that is ubiquitous to the entire process from development to operations, but at the same time well-segregated and delivered as a service to developers. This reduces developers‘ workload and allows them to consume security and identity services, instead of continually recreating these.
For Development, there is little change. It must be business-driven, (following the overarching BASIS model defined by KuppingerCole), it must be agile, and it must follow modern design and architecture principles, such as building on microservices architectures.
For efficient DevOps and supporting complex multi-cloud, multi-hybrid environments that are the reality for most organizations today, infrastructure for running the services must be provisioned and configured. Infrastructure must also grow with the business needs, requiring elasticity and scalability, which – depending on the runtime environment – is a given or must be managed by the organization. Infrastructure is also not just compute and storage, but also network. Following the principles of BASIS, which also apply to SODAS, this is provided by policy-based automation, utilizing information gathered about both the infrastructure and the requirements of the new services that shall be deployed. This requires integration of information from development, infrastructure, and other areas into (virtual) repositories, building on a common semantic, so that policy-based automation – commonly supported by AI/ML – can be applied.
Policy-Based Automation, Unified Across the Multi-Cloud, Multi-Hybrid Environments
Operations then also build on this approach of policy-based automation, unified across the multi-cloud, multi-hybrid environments. Clouds already differ vastly in the way they are managed. Additionally, between a public cloud and on-premises IT, the required level of management differs vastly due to the differences in provider responsibilities versus tenant responsibilities. However, a unified layer for policy-based automation enables organizations to abstract these differences and thus simplify operations.
This all is underpinned by the Security and Identity layer, building on modern Security Fabrics and Identity Fabrics, delivering a consistent and comprehensive set of security and identity services via consistent API layers that remain stable even when the underlying architecture changes.
Fig. 2: Key technologies involved in SODAS, integrating development, operations, and security by policy-based automation.
This all builds on the set of technologies described in the BASIS concept. For Development and Operations, DevOps Tools, but also IT Operations Management for the operations part, are essential. IT Operations Management is another vital element for the infrastructure setup and operations. Allowing the flexible shift of workloads from one environment to the other in a complex multi-cloud, multi-hybrid IT is essential, and supported by this approach. The inherent limitations found frequently in DevOps and being caused by the vast differences even in operating the major public clouds, focusing on a single defined target environment for operations are overcome by SODAS.
The Role of Enterprise Service Management
Enterprise Service Management is another essential element, for allowing a business to express its demand, and for managing all the assets and services in a consistent and coherent manner. All these elements pay into the virtual repository that provides a unified perspective across services and the environment to execute these, making the formerly unknown and dynamic known. These repositories are accessed by policies and automation solutions primarily via APIs.
Last not least, cybersecurity and IAM (Identity & Access Management), delivered via Identity Fabrics and Security Fabrics, are the foundation for delivering the identity and security services via a defined, comprehensive, and stable set of APIs. This all is well-integrated, last not least via the repository and the policy-based automation, backed by AI and ML.
Fig. 3: The key actions to take in delivering to the SODAS model.
To move from today’s DevOps towards an approach that delivers on the promise of DevSecOps and that is made to support the full range of a multi-cloud, multi-hybrid IT environment, SODAS can be implemented in four stages, following the: plan – build – deliver – run approach.
Planning is about optimizing the organization, with a clear segregation of responsibilities, but also by defining interfaces and setting up cross-divisional processes. This is about focusing, not to be mixed up with building new silos. Silos are not connected; silos are not integrated. The concept of SODAS is about focus and about leveraging the skills and specialization of the workforce in an optimized manner, supported by integration at the organizational and technical layer, and powered by policy-based automation.
Tooling Beyond the DevOps Tools Chain
To make this work, it requires the setup of the tooling, beyond the DevOps tools chain. It also requires modernizing the DevOps tools chain so that infrastructure and operations management are segregated via defined interfaces. This also allows for managing security and identity managed externally (and being consumed via APIs), controlling the DevOps tools chain. It requires working on the Identity Fabric and Security Fabric. It requires ESM and building the (very dynamic, always current) Asset Repository. And it requires policy-based automation. This is a journey, not a big bang. But every organization will already have several elements in place for building their SODAS model.
This then needs to be delivered by gathering data, by defining policies, by setting up automation, and by defining the identity and security services, the APIs, libraries, and widgets that make consumption of complex identity and security seamless to the developers.
Guiding principles for SODAS:
- Business requests IT Services
- Unified view on IT Services – one IT, across multi-hybrid, multi-cloud environments
- Policy-based automation instead of manual administration or coding
- Development is agile, consuming identity & security APIs, delivering status/requirements back to DevOps tools as well as IT Operations Management
- Automation of identity, security, and infrastructure setup & management
Our recommendation is to revisit the DevOps and DevSecOps approaches in place in the organization according to SODAS to improve security and time-to-value in delivering Digital Services.