Is Balance Really an Issue?
Every time I sit at my desk to work or try to finish the book I have been writing, I stare at these three icons.They remind me of the diffuclt struggle that architects and designers face when making decisions that will affect systems for years to come. My belief is that the saber tooth tiger on the left epitomozes the culmination of over-engineering. How did that view emerge ? When I was a child, I was deeply fascinated by paleontontology. I remembered seeing a depiction of a saber tooth tiger that sank its teeth into an elephant who was stuck in the tar pit. But the tiger’s teeth went in too deep and thus could not escape the elephant’s fate. Whether this was made up or not , it left an indeible impression upon me. An animal as imposing as a saber tooth tiger could easily misuse its greatest weapon.
On the opposite side of the tiger is the duck-billed platypus, a semiaquatic egg-laying mammal native to Australia and found in Tasmania. It is part of a genus that consists of 5 species of mammals that lay eggs. Upon discovery, Eurpoean naturalists were baffled by this almost blind, egg-laying, duck-billed, beaver-tailed, otter-footed mammal that has a poisionous hand spike to defend itself. This oddball also has the ability to find their prey via sensing electirc fields, simialr to dolphins, which explains why their eyesight isn’t as vital to them.
Evolutinary theorists have had a ball wih this animal and as a teen studying this mashup of forms, I was fascinated. I have this on my desk because to me it represents the classic joke of “design by committee,” which is no joke when it happens in real-life software projects. The laundry list of features, vestigal or otherwise, exempliflies the all-too-common practice of “kitchen sink design” found in many legacy platforms, some of which were rewrites to fix the “legacy” problems.
So what about the lion balancing on a crystal ball in the middle? Of course, that is how I view the task of balancing the needs for technical resilience, business flexibility, agility, cost, and realtime, social networking that is deeply integrated into the fabric of customer-facing applications. Analysts and consumers may not know what they want from an app until they see it. In that case, investing in pilots that could fail or take off exponentially causes all kinds of design stress.
Greenfield Application Designs Must Play in a Brown World
Freshly minted third-platform applications will incrementally take on new features and functions. As they become vital to the success of the business, they will be naturally integrated into the messy world they were formerly isolated from. This is where design meets sustainability across an enterprise. Playing nice with legacy systems that are vital part of the existing transaction and information flows often means accommodation and compromise. In my blog series over the last two years I have written about topics on design and constraints, and more importantly why applications degrade. Now as the idea of the third-platform takes off, we need to reinvestigate what truly makes a killer app in this brave new big data world. But an IT organization will not be considered a serious player at the table if it does not understand what it must do to become a strategic enabler of the business.
Why all the embedded links in this blog?
Business Demand Perspectives:
- Business value is not just hard money, it is multifaceted, including brand value and strategic positioning
- Business demand drives IT supply, not the other way around
- The world is changing rapidly and the time from prototype to mainstream is shrinking
- The business value chain that owns the app can have a positive effect on that app if it knows how to characterize what the drivers are
- If the business cares enough about an app, it will wind up having many masters and will need to be agile and resilient in the face of constant change
- Metrics are vital to understand the historical application consumption of infrastructure, but are not a substitute for understanding business demand in terms of growth and KPI’s
- Design and architecture are about meeting requirements not building an edifice to one’s ego
- Constraints appear in every design problem
- Qualities are not fuzzy, they are measurable and must be taken seriously
- Agility processes are embodied in a mind-set, aided by a tool set, not the reverse
- Our infrastructure must be elastic to meet demand and that demand must be understood and conveyed as policies that the infrastructure can act upon
IT supply perspectives
- Reference architecture stacks need to be based upon agnostic capabilities first, and then mapped to products as a second step. Why? Because products change to meet the changes in the IT supply market, and architectures are built to accommodate change in the business demand
- Technology alone rarely solves major problems; in fact, left to its own devices, it causes new problems
- Process and skill capabilities must support most technical capabilities. Any impactful capability change comprises all three types—a lesson is consistently ignored in the industry
- Sustainability and agility are companion mind-sets, you need both and you need them to be supported by an active, empowering governance process that is not a rubber stamp
- Software will run the data center employing elastic resource pools that will meet the consumption requirements of business demand as needed, in real time
- This can only be done by articulating informed policies that are created with business intent
While some of these ideas seem either well-worn or too fanciful, they are where IT is going and this book reflects those thoughts.
I will keep you posted on its release.