Architecture Principle - Everything is PorN Principle

Architecture principles are ground rules by which we develop our software. This ranges from ways of working to styles of coding, from software decomposition to business compliance, from infrastructure choices to security implementations. As you can see, it covers pretty much everything related to the development of business services, online, offline and internal.

Description

This principle assumes that in the software life-cycle different versions of a software component can exist concurrently. Traditionally this is implemented in organizations by adopting the DTAP model. A software component matures through the Development, Test, Acceptance and Production phases, where each phase has its own primary stakeholders and in many cases different SLA's, RACI matrices and ownership are assigned. In D, the developers control all facets of the component, in T no development can take place, test engineers test the component. In A, a user panel tests the correctness of the software by verifying all requirements are met and when the component is accepted it is taken into Production. This works well in environments where software components are relatively monolithic in nature, in these environments there will be more than one developer specific environments but only one T, A and P will exist.

In Service Oriented Architectures, and especially those situations where service orchestrations are the preferred means of composing applications, the DTAP model is too rigid to be usable. Within an agile environment we therefore follow the Everything is Production or Not (PorN) Principle, which means that everything is considered to be a production version, albeit that the there is a difference between the various maturity phases of the software, which manifests itself in different SLA's and different user authorizations.
In essence this means that we always deploy to a production environment, where components, services, that are still in development phase will be covered by a lower SLA than services that are already in the production phase. Additionally, those services that are in the development phase can only be accessed by 'users' that have the role 'DEV' attached to them. This is according to RBAC is everywhere.

Rationale

Within agile environments we typically assemble our applications through Service Orchestration. By 'stringing' services in a particular order we add or change new behavior of our (online) services. In reality this means that when new behavior is developed, many of the software components, services, will already exist, new components will be developed and will be in some state available to be used. As such, the new service XYZ can depend on the service implements ABC as deployed in production, and service QRS that is currently in the process of being accepted by a user panel. By dropping the DTAP model and adopting the PorN model, we ensure that new services are always developed in a scenario where either a service is being developed, or has been developed, in which case the latter scenario means that the service is of sufficient quality, Production quality.
With this setup, we can then always deploy any constellation of services in the same environment as our Production environment. The only difference between what is already production quality and what is not yet production quality is related to the services that are currently under development and those that are not. Or, in other words, the consumer of a service can be either a production quality grade component or not. Since consumers can be users, we differentiate between 'unforgiving users', for example paying customers, and 'forgiving users', for example developers or testers. Also, consumers can be other services, which either behave correctly or might behave erratic.
Thus, we have consumers that have high expectations or behave correct, resulting in a service constellation that will need to provide and can provide a particular SLA. Or we have a service constellation that has consumers that either expect little or behave badly, resulting in a service constellation that cannot provide the same SLA but doesn't have to either. Hence, it is the consumer that dictates the environment with its SLA and not the maturity of the software. Therefore we need to control which users can access a particular instance of a service.

Implication

Dropping DTAP and adopting PorN, we can no longer rely on infrastructure setup to safeguard the various maturity phases in the software development life-cycle. Instead we can do this by implementing the RBAC is everywhere principle, thus limiting the users that can access a (version of a) service that is still in development to users that have for example the role Developer. Unless the user has the role, she can't access that (particular version of that) service. Or in case the consumer is not a user but another service, that service needs to have that particular role.