Interview with Juval Lowy, President and Chief Master Architect, Idesign - Speaker at Global Software Architecture Conf - June 2 Posted on : Jun 06 - 2017

We feature speakers at Global Software Architecture Conference - SantaClara - June 2017 to catch up and find out what he or she is working on now and what's coming next. This week we're talking to Juval Lowy, President and Chief Master Architect, Idesign (Topic: Workshop: Zen of Architecture)

Interview with Juval Lowy

1. Tell us about yourself and your background.
I have been a software architect my entire career. I have spent the last 20 years focusing on architects, on the person behind the job, the skills and the techniques you must have in order to succeed. I am the founder of IDesign, a company devoted for doing nothing but software design. I have personally mentored hundreds of architects the world-over in my seminars and on-site engagements. I published some half dozen books and 100+ articles on my ideas and techniques. Microsoft recognized me a software legend (something they only awarded to 6 people so far) due to the impact I have had on the industry.  

2.  What have you been working on recently?
Recently I been working on making the actor model more approachable to architects and decision makers. The Actor model dates back to the 70's, to a time before Moore's Law taking off. At the time there were two ways of computing: the sequential, centralized way (this is what the C in CPU was for) using an expensive large computer, vs using lots and lots of simple processing units to compute in parallel. Well, the parallel hardware  never became mainstream, Intel was too successful with the 8080, Moore's Law was too compelling, and we never looked back. But now, with the demise of Moore's Law (we can't make it any faster), and the inability of most developer to take advantage of multiple cores due to the synchronization challenge, the industry is examining the road not taken. With the availability of mass computing, we can use software to emulate a mesh of small processing units, and use messages and addresses instead of wires. This is what the actor model is all about and it will  be the only way to build the Greater IoT, with trillion of devices, all spewing dynamic concurrent live data. Another advantage is that this approximates much better just plain old business processes. The issue is that sequential programming is accepted as "THE" way to program, so there is a lot of work to change people minds and provide them with the right tools and framework to make the actor model approachable.   

3. Tell me about the right tool you used recently to solve customer problem?
The answer, surprisingly, is not some nice architecture or cool technology. It is project design. Much as you need to design the system, you must also design the project to build it: from scheduling resources behind the services, devising several good execution options for management to choose from, to validating your plan, and accommodating changes. This requires understanding the inner dependencies between services and activities, the critical path of integration, the available floats, the staff distribution and the risks involved. All of these challenges stem from your design and addressing them properly is a hard core engineering task – designing the project. I have developed a series of ideas and techniques for project design, and it is in essence a new branch of software engineering. Using the architecture as a starting point I am able to quantify the risk, use risk as a planning tool, tie it together with the cost and schedule, and devise multiple options of building the system. The results we see with our customers are exactly what you would expect: on-schedule, on budget, on quality, every time.

4. Where are we now today in terms of the state of  Architecture?
Where are we? In a deeper hole. The industry simply does not get that virtually everything that they do as "best practice" is wrong. Time and time again architects resort to functional decomposition (doing the architecture based on functionality), while it is a universal design rule that the only way to decompose a system is based on volatility (areas of change). Another universal design rule is that the functionality or the features are the result of integrating areas of volatility. In anything, features are always aspect of integration, not implementation. My body does not have a box called "conduct a conference session", and my car does not have a box called "take me from A to B". Your house does not have a box called "cooking". You do all that by integrating components that have nothing to do with the features. Functional decomposition is the kiss-off-death, and why most systems are so insanely complex. The latest fad is microservices. I am actually credited with coming up with the idea, but I predict that in most cases it will be a failure.  The reason is simple: while giant monolith of service never worked (and why I have been evangelizing the concept of literally every class as a service for more than a decade now), the way most architects perform the decomposition into microservices is based on functionality, which not only is precluded from ever working and will always make system impossible to maintain, but now they also have the inherit complexity of managing services and multiple moving parts. Adding malignant Agile to the mix is making it all so much worse. But people are much more interested in "doing" agile than in "being" agile. Doing Agile is easy. Being Agile is hard work. Plucking use stories off the Kanban board and coding them is the epitome of functional decomposition. Integrating well-designed services into features requires first and foremost investing in system and project design, and getting both of design aspects right. Ironically, the more agility is required, the more investment in system and project design is required.  

5. What are some of the best takeaways that the attendees can have from your "Zen of Architecture Workshop"?
In my workshop I will discuss how to properly decompose a system into modules, using volatility, or areas of change. I will contrast it with the most common mistake done in architecture, using functionality to identify services. I will show how to overcome the real hurdles architects face pursuing volatility-based decomposing, simple and practical techniques for identifying areas of volatility, common telltale signs or "smells" when your design is still functional when using IDesign's approach for system architecture. None of this is a silver bullet – nothing ever is, but that does not mean you should do things the worst possible way. Volatility-based decomposition will give you a fighting chance. You still have to fight, but at least you have a chance.