Juval Lowy’s Master Architect Class

  • Article

Juval Lowy

 

Once a year, Juval offers "The Architect's Master Class." I will attempt to capture some of Juval's words of wisdom. It is a real pleasure to be here.

The class is called "The Architect's Master Class," and runs 9 hours a day for 5 days. You can learn more about this class at www.idesign.net. The class is targeted at Architects, Software Engineers, and Project Managers. At a high level the class is about best practices, pitfalls, tips, and design guidelines.

The kick off is that software is in crisis. There is even a wiki entry for it:

One core reason is cost, in terms of initial development and in terms of cost of overall ownership. Juval says companies go "clean slate", where the unacceptable cost leads to a total re-write. Why are costs so high? First, we solve the wrong problems, often "gold plating," missing core functinality in the requirements and adding bells and whistles. Often times the system is obsolete by the time the product is released.

The problem is often traced to chaotic organinzations. Many firms lack a clear process and cannot repeat previous successes. Firms also lack a structured knowledge retention process. The lack of success can also be seen through customer complaints, as evidensed by the Better Business Bureaus's Top Complaints, where complaints often relate internet shopping, cell phone operation, etc – all rooted in software.

An initial assertion is that software is too expensive:

  • Initial Development is most expensive
  • Overall ownership is huge
  • Gets too expensive to add features
    • Many people go to clean slate, which is an admission of failure

The two main issues is that developers solve the wrong problem and projects are difficult to staff. First devs add too many "cool" features and not enough core functionality. Juval calls this "Gold Plating." Second, code is often unmaintainable by new staff.

Not like any othe engineering discipline

Compared to other engineering disciplines, software has no regulated licensing process or industry standards. You can just call yourself a developer without having a formal CS degree. In other engineering disciples

Not like any othe engineering discipline

Compared to other engineering disciplines, software has no regulated licensing process or industry standards. You can just call yourself a developer without having a formal CS degree. In other engineering disciplines you go to jail if a wing falls off a plane or if the elevator cable breaks.

Software is not peceived as a profession. Developers are 'geeks' or 'hackers.' This perception has allowed software to be offshored and commoditized.

Science versus Engineering

Engineering is about scientific principles toward a practical result to match some given requirements. Science is about getting knowledge through observation and experimentation. Science is typically for other scientists. Engineers report to customers. The key lesson is that we need more "Engineering" in "Computer Science."

Real Terminology

Software architects are really engineers. Software engineers are really programmers or developers. Software Developers are really just code technicians. In summary, software architecture is engineering and software development is manufacturing.

Call to action

Software development needs to be more like an engineering discipline.

Types of Architects

The Enterprise Architect is sometimes called Corporate Architect or a Chief Architect. The goal of an Enterprise Architect is to utilize economies of scale. Responsibilities include: (1) corporate level frameworks; (2) Direction and guidance; (3) Managing other architects.

A Solution Architect is sometimes called a Lead Developer and is often application specific. Responsibilities include top level design and sometimes providing a detailed design. Solution Architects often provide technical leadership and reduce complexity and provide infrastructure. Solution Architects focus on the what and not how. They colloborate with product managers and project managers. A Solution Architect is a:

- Process Lead

- Technical Lead

- Design Lead

Architecture Goals

Architecture should not be tied to business specifics and should be about best practices and patterns that transcend specific applications. Well architected code should transcend industries, products and team sizes. Architects are not about the problem domain; they are about the business. Architects rely on other domain experts: (1) System experts; (2) Developers; (3) Analysts.

Service Oriented Architecture

What is a service?

Ideally, it is a single WCF class.

Biggest Risk to a project

Not having a skilled architect. Best scenario is to have one single architect and one junior architect. One developer can work on one service. This is a good map. A good metric is to assign a team to one assembly.

High Level Design Goals

A good design minimizes interactions, has loose coupling and includes encapsulations.

How to integrate service construction

Create a service dependency graph, which shows which services depend on other services. The start a bottom up integration plan, where you start plugging in the lowest level services into higher level (consuming) services. The goal is to reduce risk and discover incompatibility earlier. Moreover, it is recommended to do daily builds and possibly regression testing (re-running previously run tests and checking whether previously fixed faults have re-emerged).

How to test service calls

EVERY service should have its own test environment. This leads to robustness and gives management signs of progress. This allows you to spice up boring testing. The goal is to test all method calls, callbacks and errors. The goal is that our test harnesses will always uncover errors so that are software doesn't have to.