Friday, January 25, 2008

Frank Lloyd Wright

Frank Lloyd Wright, one of the most famous American [building] architects of all time, worked on over 500 structures and left a few notes of wisdom for us to consider. While the comparison between software and building architecture breaks down pretty quickly, the quotes below apply to both disciplines.

  1. A great architect is not made by way of a brain nearly so much as he is made by way of a cultivated, enriched heart.
  2. All fine architectural values are human vales, else not valuable.
  3. An architect's most useful tools are an eraser at the drafting board, and a wrecking bar at the site.
  4. Every great architect is - necessarily - a great poet. He must be a great original interpreter of his time, his day, his age.
  5. Form follows function - that has been misunderstood. Form and function should be one, joined in a spiritual union.
  6. Get the habit of analysis - analysis will in time enable synthesis to become your habit of mind.
  7. Less is only more where more is no good.
  8. The architect must be a prophet... a prophet in the true sense of the term... if he can't see at least ten years ahead don't call him an architect.
  9. The architect should strive continually to simplify; the ensemble of the rooms should then be carefully considered that comfort and utility may go hand in hand with beauty.
  10. The truth is more important than the facts.
  11. "Think simple" as my old master used to say - meaning reduce the whole of its parts into the simplest terms, getting back to first principles.

Constantin K.
Firebrand Architect™

Wednesday, January 23, 2008

Static, Runtime, Physical

For the spring 2008 semester I function as a distance education instructor for the Principles of Software Architectures course offered by the School of Computer Science at the Carnegie Mellon University through the Institute for Software Research International. As I reviewed the course I fondly remembered the lectures by Prof. David Garlan and Tony Lattanze while pursuing my Masters in Software Engineering (IT) degree some years ago. At the same time I reflected on the architecture representation practices employed on some of the recent projects I’ve reviewed and sadly the state of affairs is looking pretty grim.

It is still common to see software architecture designs mix incongruent design elements together, such as combining message flow process with a class diagram. As a gentle reminder, architecture of a software system is represented through a number of views that describe some angle of a system. There are many different views that can be chosen by an architect to represent some aspect of the system (e.g. process view, deployment view, decomposition view, etc.). No matter what view an architect chooses to document some aspect of architecture it’s critical to understand that most views can be classified into static, runtime, and physical. It is absolutely critical to maintain conceptual integrity of a given view; otherwise you may be comparing apples to oranges. If this is new to you read a copy of Software Architecture in Practice, Second Edition, take this course from Carnegie Mellon, or take a class from the Software Engineering Institute.

Constantin K.
Firebrand Architect™

Sunday, January 20, 2008

Evolving Opportunistic Solutions

Opportunistic projects (software solutions) are the essence of the progress in all organizations. These projects provide valuable ad-hoc gains in productivity to the people who need help the most. Such projects usually don’t have a formal budget, have one or a few people running it, and usually reside outside of enterprise architecture environment or go against the formal way of doing things. But these projects exist because they provide the benefit the core IT organization cannot.

One example may be auto generation of pre-canned reports for a loan processing clerk. In this case an existing FICO score provides good information about the risk level of a potential borrower, but a loan procession clerk may get an additional level of insight, and reduce risk to the bank, by looking into additional publically available information. Usually opportunistic solutions target a small specialized niche, such as pre-canned reports for farm machinery loans. But as loan officers across bank divisions talk to each other, they find out that these reports are insightful for other loan types, and eliminate the need to do manual research. Now all loan officers want these reports to be included as part of their loan application paperwork. Loan division chief requests the opportunistic software solution owners to provide reports to everyone. Will this work?

A responsible software architect who recognizes this situation needs to act fast. There are many red flags in this scenario that may turn a well respected idea into a disaster. First, it should be clear that unless the designers of the opportunistic software solution thought about scalability and extensibility during design it may not be possible to produce more reports without rethinking entire approach. Perhaps the solution taps into an already overtaxed database system that goes offline periodically. Secondly, the growth problem may not only be technical in nature. May be the business process supported by the software solution is not scalable. It may be that the software generates reports and emails them to users automatically, but requests for reports are being processed manually. Perhaps the reactive response to support the requested increase in demand would be to add staff and throw hardware at the problem. That may last for some time, if system allows multiple users, but eventually the opportunistic solution will require features that can only be obtained from enterprise services (e.g. SMTP service, enterprise auditing, directory services, etc.).

The moral of the story: build on success of opportunistic solutions. Recognize patterns, analyze change impact, educate solution owners on the natural evolution of successful opportunistic solutions and on the differences between ad-hoc and enterprise solutions, understand how requested change fits into the existing and future organizational enterprise architecture, and finally show the solution owners that the demand for their service will only grow with time.

Constantin K.
Firebrand Architect™

Saturday, January 19, 2008

Edward Hopper - Communicating the Essence

It’s the architect’s job to decide and communicate which quality attributes need to be emphasized in order to achieve the overarching mission of a solution. Similarly the iconic American artist Edward Hopper, in his paintings, captured the essence of a scene while abstracting the negligent elements of the situation.

In painting Haskell’s House you clearly see that the artist chose to omit the wires from the electrical poles. The busy harbor behind the house is not depicted in the painting: the core emphasis is on the house. Also notice how the sun rays draw your attention on the house and you can almost forget about the mundane details of trees, landscaping, and electrical poles. A software architect has a similar job: capture the big picture (e.g. security, environment constraints, composition of services), but note the critical solution qualities (e.g. usability, performance).

In the infamous painting, Nighthawks, Edward Hopper uses light and shadows to concentrate viewer’s attention on the situation in a dinner. Notice lack of pedestrians, cars, or any other artifacts that would detract from the developing situation inside of a dinner. The viewer may dully acknowledge the presence of outside, but all the attention is concentrated on what is happening on the inside. Similarly an application architect that works in a mature design environment simply needs to acknowledge the presence of certain assumptions, but concentrate his work on the essence of a solution.

The 1940 painting Gas shows a lonely attendant at a gas station. There are no cars fueling or on the road. The obvious, cars, is not commuicated.

If you ever have a chance to see a collection of Edward Hopper’s paintings do not miss that chance. A closer look at the paintings can be found here.

Constantin K.
Firebrand Architect™

Saturday, January 12, 2008

Enterprise Standards

What kind of hardware & software environment exists at company Foo and how do they handle similar challenges? How will organization Foo evolve over time? Few organizations publish their enterprise architecture specifications; after all, a refined purposeful architecture is a competitive asset. But some organizations publish such information. If you search for MS Word or PDF documents for keywords such as “Enterprise Architecture principles”, “enterprise standards”, “to-be EA”, you will find a few valuable resources. One example is an IT Standards document for the US state of Kentucky. The freshness of the resources will vary, but discovering and learning from other organizations is a good way to gain new perspective and judge your organization’s software and enterprise architecture approaches.

Constantin K.
Firebrand Architect™

Blockchain learning path for Enterprise Software colleagues

I wrote this post to document my learning path of blockchain concepts and Ethereum technologies while keeping my “new to blockchain” collea...