The Corporate Boundary: Process, Governance, and Perception
Working with both cloud technology and platform engineering during time, you often hit the corporate boundary of the existing process, governance or security framework for what is allowed, what is accepted and what is acknowledged and perceived as “accepted” in the organisation. Usually, these is purely perceptions about what is allowed or not hence no rule to attach this to but that’s a story for another article.
How often have you tried to introduce a new component, a new service or a technology component and got the immediate feedback that this is not allowed, not approved or not something we “normally allow“. When you have been through your portion of enterprises, you learn that the rules of allowance can be bended alot but often the root of this kind of feedback is based on my experience not founded in rules, governance or written policies but merely a result of people being busy and not having time to evaluate yet another new thing.
When people become too busy, they loose the ability to foster creativity and service development and thinking in new products with new processes and new ways of working is a tough cocktail, if your schedule is already 120% booked.
Abernathy’s Productivity Dilemma: Then and Now
When William J. Abernathy in 1978 wrote about the productivity dilemma in the automotive business, he didn’t realize how well these theories and thinking fits the platform engineering and technology innovation working with cloud. He was ahead of his time for sure.
The productivity dilemma described by Abernathy refers to the conflict between the pursuit of productive efficiency through process innovation and optimization and the ability to maintain innovative capacity for new products. In the context of manufacturing, firms that focus on refining and optimizing their production processes may become less flexible and less capable of introducing novel product innovations.
In IT, this dilemma can manifest when an organization focuses heavily on refining and optimizing existing technologies, architectures, and processes, potentially becoming so efficient that it becomes resistant to adopting new technologies or innovative approaches that could disrupt established methods. As IT systems become more standardized and refined, the organization might struggle to adapt to new paradigms (like cloud computing, machine learning, etc.) due to a rigid technology stack or a supportive workforce skillset deeply specialized in mainly VM based technologies in classic hosting.
Working with cloud and technology in this space taught me that the organizational view on doing things differently usually is what stops your project much more often than written rules and official rules/policies. When you engage the existing and well established IT department and talk about cloud, serverless instances, cloud-native and all the jazz, the usual feedback you receive is “that not how we usually do it” or “you should consider to run this on a virtual server, we already use these” and for sure these are well adopted and matured.
Enterprises do transform, and so do services and platforms within. But people and mindsets are not following in the same rapid pace and perception of “best practice” is usually where you stop and consider if its at all possible to introduce new services in this “company”. But let’s face it, its much more convenient as employee to do what you did yesterday than consider to do something new, something we didn’t think was possible to do in a different way. Back to Mr. Abarnathy, his point was exactly that well established organizations become more and more efficient in their operations and with more and more optimized control and eagerness to perform better, the organisation loose in the technology and innovation space, working with innovative process development.
When you engage the existing and well established IT department and talk about cloud, serverless instances, cloud-native and all the jazz, the usual feedback you receive is “that not how we usually do it” or “you should consider to run this on a virtual server, we already use these” and for sure these are well adopted and matured.
Back to Mr. Abarnathy, his point was exactly that well established organizations become more and more efficient in their operations and with more and more optimized control and eagerness to perform better, the organisation loose in the technology and innovation space, working with innovative process development.
Fighting the Status Quo: When “That’s Not How We Do It” Wins
I have managed to introduce new services or a new technology and this takes an effort. Countless alignment meetings, resource allocation requests, requirement alignment sessions, and lesson learned sessions later, you are finally approaching a completion point…now we are almost at the finish line, we are soon ready and the sun is shining on you…if you are not dead or exhausted from the process or lack of same. Bigger enterprises who already has an established governance framework, the effort of getting new services defined is way bigger that building the actual product itself. And then, in the sunset comes the kicker…
The Security Rubber Stamp: A Curveball at 95% Completion
Just before the already delayed go live date of your product launch, someone in the organization feeling uncomfortable about such a new thing you have proposed senses, that this new product is close to launching but also recons that this is new business so a curveball hits you. The notorious security approval/rubberstamp is popping like a mushroom and questions is raised… has security actually been involved, have security been a part of the journey, have security assessed this and how is this now secure when not VM based in our datacenter, can we trust this? Why not a zero trust approach to this?… and then the corporate circus repeats itself like a dump LP record in the same tune as the hour before.
When all comes down to organizational behaviour of introducing something new, the organization and all its stakeholders obviously has this mandated obligation to raise the security whiteflag which is the ultimate red flag for full stop and nobody needs to argue if a security argument is a valid argument, everyone want security (even without considering the consequences of stopping the service/Product from launching). Who would EVER argue that we don’t consider security hence nobody will challenge your argument if you raise the security flag on a new solution and eventually, that’s what the true corporate cowboys are doing when they are at the 95% status point of go live for the new service. And secondly, when you are faced with security related requirements, its your problem because you brought this service to life. Its never EVER security’s responsibility to deliver input on how things should be done instead. So back to the startline.
Breaking the Cycle: The Security Participation Paradox
Fun fact, I have often again and again asked our security department to participate and engage from the first step of the design and/or implementation of a new service to mitigate the above scenario from happening. The most frequent feedback you get is usually, that security only is an advisory function and the service/product/platform should be designed and build and THEN security can assist with the assessment… or that I didn’t raise a resource allocation for security in a specific workload hence security should be engaged sooner, later or just whenever it fits security… and history repeats itself ! Or you forgot to raise a request for security about this…or… find the remaining examples in your memory 😊
Conclusions
If you want to introduce new services in an organization where someone else but yourself should review your architecture, consider a few key takeaways from the above.
- Include the people that is your biggest opponents from get go
- Get security commitment and involvement throughout the entire process and if security is not picking up the phone, have them to write the approval before you start
- Make sure the team that should support the thingy you are designing plays a pivotal role of designing it as well.
- Allow red tape in the first iterations. Nothing was build perfect in the first versions so allow for key features not available in the first build. (no, its still not a MVP!)
- Security readers: consider productivity and development in every aspect of your engagement with new services and if possible, hire developers to your security department, not enforcement administrators ! You play an vital role for new products if you engage in the earliest possible time of the development. Think about how artefacts can be secured from the time, they are written and defined!
- Try to convince yourself that its a journey…(I call BS on this one by myself!)
In the end, regardless of if you follow above or don’t and get to the finish line of your product launch and managing to get the security rubber approval, remember to have fun all the way. That will make all the meetings and approval gates just abit more fun to attend.
A final hint
PS: small hint 😊You will at least once during this article find all the BS words or concepts mentioned in the previous days during the article.