Some have said “It’s all relative.” If the statement were true, then it could not be proven false. By nature, relativity cannot be proven true or false. Therefore the statement itself cannot be proven to be true.
Others say “It’s all in the execution?” (referring to value). If the statement were true, then Design could not exist. There would be no value possibly created in the design process if all of the value were contained in some form of execution. The value of design is in its ability to show patterns of what is desired. For the purposes of software design I am specifically referring to the value created in patternizing a desired set of functional and non-functional requirements. The design process creates valuable output which may manifest itself as a cohesive implementation such as an appliance or Macbook Pro or Iphone. These are just examples. The design process may also create output which is intended for further execution such as a template. If all value existed in execution, templates would not exist and no one would pay for them. I am not asserting that willingness/ability to pay at a given time is the sole indication of value in today’s markets of often politically driven consumer behaviour (i.e. boycotting a product or service which supports an percieved opposing interest faction.) I would yonder far enough to say that the only thing “all in the execution” is the absence of credit, if that’s a thing. I suppose design plagiarism is just one example of one type of plagiarism which is “all in the execution.” Notice it does not create value, but rather changes the consumer’s perspectives of value in such a way as to fundamentally distract the consumer from the value of knowing the originator of a specific work. If the consumer knew where the true source actually originated from, they may or may not choose to pursue the originator. If the consumer isn’t given the option of knowing where the true source actually originates from… I have to ask “why not?” <3
Design Culture + Test-Driven DevOps = Test Driven DevOps Design
If you are familiar with Test Driven Development then this should be no mystery. Test Driven Development has been around long enough for basic understanding. From a cultural perspective it teaches the acceptance of failure in the first iteration. Once the test passes, further development inevitably occurs. Operators are familiar with similar approaches for test-driven deployment and quality assured change management. When infrastructure is code, the process of deployment becomes more transparent across development and operations groups via test-driven quality assurance processes which are often codified into tools.
In Test-driven DevOps Design the tools are the output of a previous iteration. This is made possible by not just infrastructure-as-code but template-driven-test-automation. On my sabbatical I have identified 4 fundamental design constraints which I have applied to a Domain Specific Language (DSL) known as STRAP (Service-Templates Running A Process) implemented by a hyperscale PaaS known as GitStrapped. The 4 fundamental design constraints also define the domain:
— #STRAP♕USIR™ (@STRAPUSIR) April 26, 2013
Each STRAP in the GitStrapped hyperscale PaaS follows these constraints to ensure higher velocity with each iteration. I call this USIR-friendly.
Design Culture Adds Value Beyond Execution with Every Push
In design-culture there are often celebrations following a successful release, and when releases happen frequently celebrations may also occur frequently. I have found the velocity itself to be a worthy reward, but I am privileged to be surrounded by others who embrace the culture of design which gives credit to a design contributor any time a contribution is made. I have witnessed value being added back as I become connected to many pioneers in software design due to paying respects to those who came before me. With Test-driven DevOps Design, much execution is automated, reducing and containing errors in parallel execution domains. I don’t miss the “race-conditions” along critical paths, either.
So what does it look like from a Process / Business Perspective?
Test-Driven DevOps Design can be applied to existing project workflows such as Kanban or applied to a Service-oriented Modeling Framework such as the one shown in this diagram by Sean Fox:
This diagram is useful in illustrating one possible application of a Domain Specific Language such as STRAP (Service-Templates Running A Process) atop a hyperscale PaaS such as GitStrapped for Discipline-specific modeling as an iterative process. Sean Fox’s diagram is also useful in illustrating one possible workflow which encapsulates business needs, determined in an analysis process, as part of a longer iterative process where the input is a service concept (or pattern of service-quality desires, requirements and other new ideas) and where discipline may produce a solution of services as output according to design constraints.