For more than four decades, my focus in the information technology (IT) industry has been on systems engineering – designing, architecting, configuring, and representing computing systems to buyers, organizations, and operations. By computing systems, I mean collections of hardware (compute, storage, networking), software (OS, management, application, et al), services (implementation, operations, support), and ancillary components.
Early on in that experience, I read that all machines are amplifiers. When I first came across that statement, it was an epiphany for me. Until that moment, I had thought amplifiers referred to a unit in a stereo stack or what you plugged your guitar into.
Based on that epiphany, as I spent my days in doing the work, or leading organizations doing the work, of putting together computing systems (as both buyer and seller), I determined IT, being a collection of machines, could be considered as similar amplification, albeit on a much broader scale and with greater reach, with the ultimate goal being to drive humanity to a better end state – amplifying productivity, capability, and creativity.
As I gained experience, I developed a stepwise way of thinking that enabled me to engineer solutions built for purpose and entailed. Broadly, the following steps:
1. Determine primary purpose
2. Design for balance and scale
3. Consider costs and economics
4. Ensure strategic business fit
5. Fit to tactical operating model
In this blog, I’ll cover the first three points, taking the perspectives of those who build, sell, and service computer systems. Then, in my next blog, I’ll cover how this translates into business and operations fit. Buckle up, it may be a wild ride!
System design for primary purpose
Founded during the 1960s and located on opposite sides of the Stanford University campus were two government-funded research labs, pursuing fundamentally different philosophies. The first felt that powerful computing machines would be able to substantially increase the power of the human mind. The second had the goal of creating a simulated human intelligence. One group worked to augment the human mind, the other to replace it. These efforts and the lab’s journey are well documented in John Markoff’s book, “What The Dormouse Said – How the Sixties Counterculture Shaped the Personal Computer Industry”.
While the book focused on the race to deliver personal computing, I find the ideas also apply to general computing. My first design principle is to consider which of these two purposes are being addressed, as that informs the general design and configuration required for the intended purpose. To be fair, the majority of use cases over recent decades have been around augmenting, rather than replacing, the human mind. It has taken more than six decades to realize both aspirations, but I think we can say that, today, we are arriving at both.
Augmenting the human mind proved the easier of the two to deliver. With general consumer availability of the personal computer (PC) in the 1980s, this aspect of computing was arrived on our doorsteps in its fullest and highest ideal, in my opinion – freeing humans to be individually productive and creative, and changing the way education and business was done around the globe. Humanity rocketed forward and has not looked back since.
Replacing the human mind, Artificial Intelligence (AI) is now becoming commercially viable and available at our fingertips, whether for personal or business computing. It is maturing rapidly, being implemented at breakneck speeds, and will revolutionize how computing is designed and deployed in every aspect from this point forward. It has come to us somewhat later than its 1960s sibling, but its impact will be no less revolutionary. What is the ultimate end goal? An intelligence that can operate itself and, perhaps, every aspect of humanity.
Meanwhile, automation on the augmentation side also advances lickety-split for productivity and efficiency purposes. It’s still a human world, but our cycles continue to be freed up for whatever purpose we can imagine or aspire to, be they business or personal endeavors.
From a high-level and fundamental compute standpoint, augment or replace add up to all it really offers, at its essence. Both aspects must be the starting point of any system we design. We must account for either or both in our systems engineering.
Systems engineering and design are more detailed and complex, of course. The primary task has always been simple in concept – to move bits (bytes) of data into the processor registers where it can be operated upon. That is, get data as close to the processor as possible and keep it there for as long as practical (i.e. affordable). Sounds easy enough, but in practice it can be a surprisingly difficult and expensive proposition with a plethora of trade-offs.
There are always trade-offs in IT. You can’t have it all. Even if it were technically feasible and attainable, you couldn’t afford it or certainly would not want to in almost every case. To accommodate this dilemma, we’ve created a chain of different levels of various data storage and communications, designed to feed our processors in as efficient and effective a manner as practical, enabling them to do the ‘work’ we request of them.
For me, then, understanding computing is, in essence, simple. Firstly, am I solving for augmentation or replacement? Secondly, where’s the data, and how can I get it where it needs to be processed, or govern, manage, and curate it effectively? This opens up a target-rich environment of problems for clever computer scientists to solve: therein lies the opportunities, trade-offs, and costs that drive all decisions to be made and problems to be solved from this point on.
And one does not simply store, retrieve, manage, protect, move, or curate data. That stuff explodes in volume, variety, and velocity, as we are wont to say in this industry. These quantities are growing exponentially. Nor can we prune or curate it effectively, if at all, even if we wanted to. In an AI world, a complete data set is required.
Amplification, indeed.
System Design For Balance and Scale
At this point was have determined the purpose we are solving for, and we are looking to get our data as close to the processors as practical, so we can get ‘work’ done to support that purpose. How, then, do we define that ‘work’ and design a system for best performance, throughput, capacity, connectivity, scalability, availability, and so on? To do this, it must be well-balanced and as independently scalable as practical, at every point in its architecture.
The concept of balanced systems traditionally relates to keeping CPU, Memory, and IO in balance for best performance and throughput. Certainly, we should adhere to these, and in this distributed world we can add network, as well as considerations for reliability, availability, serviceability, connectivity, interoperability, et al. While this may seem daunting, but you can start with the fundamental balance of CPU to IO – the worker and the work. Everything else follows from that point, in my opinion.
In the 1970s and into the 1980s, two IBM Fellows named Joseph Major, and Thomas Beretvas developed a model for measuring a unit of work they defined as a CPU quanta – the CPU resources required to do one unit of IO. You could then test processors to determine the amount of quanta they could perform, and you could model data storage subsystems and memory subsystems to size them in balance with processors.
CPU quanta could be measured and compared as technology advanced. Architectures and systems could be designed, maintained, and readily compared. If you knew the quanta, you knew the boundaries for IO design. If you knew the IO load, you knew the boundaries for processor and memory design. Knowing IO loads enabled you to configure network and channel transport for those capacities and necessary performance. It became a simple math exercise to determine the necessary bits to accommodate any workload. Through various mechanisms, you could independently scale the components to their rated capacities and for their expected growth.
The cost of any workload or application could be determined by compute, memory, storage, network, et al, to process. From there, it became a matter of determining communication and synchronization: compute models existed to keep the caches correct and communicate across networks. From all this, you could calculate prices and costs, which was little more than a game of trade-offs resulting in an economic exercise.
The same concepts still apply today, albeit against more models and components. Some have simplified the exercise with converged systems and such, but the concept of balance and scale still applies.
Balance and scale. Beautiful.
System Design for Costs and Economics
There are many ways to skin the system design cat – even within the constraints of balance and scale. It is a relatively simple spreadsheet exercise to architect IT solutions and price out these solutions. The ticket price of such solutions does not equate to their costs, however: you will need to consider total cost of ownership, the return on investment, the time to value, or other such measures.
While you should beware the sticker shock of solution pricing, the economics can nonetheless be readily determined. We have developed a number of tools to make this an iterative exercise to get to the ‘best’ cost model or economic, fit depending on how that is defined in the situation or circumstance. Overall, the value of any solution should be net-positive, that is, its benefits should sufficiently outweigh its costs to merit action.
This brings in concerns relating to competition, as yours won’t be the only option to consider. The IT business is a game of leapfrog. As an IT manufacturer, supplier, vendor or service organization, you might, at one point in time, have some form of technical or economic edge. However it’s ephemeral, you can’t keep that edge. Someone, somewhere, will leapfrog you. How many businesses in this industry, from as little as ten years ago, are still around today? How many crop up each year with the next shiny new object or fabulous widget? Anyone’s edge is fleeting. Still, technology companies believe it is enough to build businesses on. So, they do, and then they hustle to maintain and improve their offerings – or they wither and fail.
Design for cost should be the easiest step in the process to accomplish, as it relates entirely to determining cost-effectiveness. However it can also be the most time-consuming, requiring several iterations to get to an acceptable set of trade-offs, perhaps developing and assessing alternatives along the way (the most normal approach). Trade-offs for feature, function, technical value, performance, capacity, reliability, availability, serviceability, security, addressable market, competition, and so on are on the table at this stage and must all be considered to arrive at a final answer.
Options can be legion. But ultimately, one will need to be agreed upon, between seller and buyer, as the best of the bunch. Costs and economics are simple enough, but sellers can only take things so far, and the ultimate arbiter of success is the buyer. Not all solutions are taken and implemented, however powerful they may be in design. Why? The value of that solution may not be apparent, known, or acceptable. Value, like beauty, is in the eye of the beholder – in this case, the buyer.
To determine value, you must address strategic fit for the buyer’s business, and their decision criteria for buying. You must also take into account how your solution impacts the buyer’s operating model. Further, the perspectives on these will vary by persona in the buyer’s organization. Executives, architects, and engineers have unique decision criteria and operational concerns; they will each have differing urgency to act. As a seller, you must address and align the varying buyer perspectives on value.
That, though, is a conversation for the next blog. See you there!
The post Systems As Amplifiers Part 1 – Building a Technology Business appeared first on Gigaom.
from Gigaom https://ift.tt/cDKhqoC
Blogger Comment
Facebook Comment