Archive for the ‘Architecture’ Category

Book – 97 Things Every Software Architect Should Know

September 19, 2010

I enjoyed reading the 97 Things Every Software Architect Should Know and not long time ago I found that is maintained by the publisher an unedited original text of the book.

I hope that these will make you curious to sip wisdom of some of the leading software architects. Here are some for the thirsty:

Architecting is about balancing: “In summary, software architecting is about more than just the classical technical activities; it is about balancing technical requirements with the business requirements of stakeholders in the project.

Architectural Tradeoffs: “Every software architect should know and understand that you can’t have it all.

Challenge assumptions – especially your own: “Facts and assumptions are the pillars on which your software will be built. Whatever they are, make sure the foundations are solid.

A word of warning, don’t expect a technical recipe of coding, it might appear elusive and witty as any of the old aphorisms, this is a modern apophthegmata laconica. You might wonder why 97 and not 78 as in the past, or any other number.

It’s a strong prime :-)

Which is, of course, true, but neither particularly useful nor the actual reason. It’s 97 because that is conveniently close to 100 without actually being 100 or trying too obviously not to be (e.g., 99 and 101). It’s around 100 because that allows for a diverse range of short items, each occupying two pages in printed form, and amounts to a reasonably sized book. The specific number 97 was chosen by Richard Monson-Haefel, editor of 97 Things Every Software Architect Should Know, the first book in the series – by definition, all other books in the 97 Things series are somewhat bound to follow the mould!

Significantly fewer items and either the items would be longer, less diverse and more like ordinary articles, which would discourage people from contributing, or the resulting book would be more like a pamphlet. Significantly more items and the items would either have to be shorter, making them little more than abstracts, or the resulting book would be too long for what it’s trying to do.

It is not the only compilation of wisdom that O’Reilly is spoiling us, there are more, and there is 97 Things Every Programmer Should Know, and 97 Things Every Project Manager Should Know.

BTW there is also a webcast (10 Things Every Software Architect Should Know).

Looking into the Maemo Multimedia framework

December 28, 2009

Maemo is a software platform developed by Nokia for smartphones and Internet Tablets. This software platform is based on the Debian Linux distribution. This last fact is interesting as Nokia was making an investment in the Symbian platform. Each of the platforms have an open character which can attract participation for sustaining development ecosystems. At this time I do not intend to analyze the ecosystem landscape vis-a-vis to iPhone, Android, WebOs and Windows CE, or why Nokia is supporting multiple platforms. The platform comprises the Maemo operating system and the Maemo SDK. The open character of its architecture provides an opportunity to study it and to analyze some of its decisions. Multimedia Framework is a key component of the Maemo Platform. It is interesting to follow the evolution of the multimedia architecture for Maemo 2, Maemo 3 and Maemo 5.

Maemo2 multimedia architecture diagram

The media server daemon is removed from the latest Architecture documentation having the GStreamer assume a more central responsibility. The Gstreamer is a rich multimedia framework that provides application the ability to treat uniformly a variety of hybrid system use cases (it would be nice to have an accurate requirement spec). The OpenMax Intergration Layer software package is introduced along with the GStreamer framework. OpenMax IL provides the processing entities, an abstraction of software and hardware resources, exposes the resource constraints for a given scenario instantiation and its processing entities interchange buffers.

Maemo 5 Multimedia architecture diagram

Maemo relies on TI’s OMAP platform, resourced with an ARM – DSP dual processor, with GPU (Graphic Processing Unit) and ISP (Image Signal Processor). All these computation accelerations are supporting rich multimedia requirements. Also it is interesting to see that TI is promoting its hardware platform and provides its OpenMax and GStreamer software implementation. It is worth to mention the bridge binding ARM CPU to DSP allowing offload tasks from the ARM processor to the DSP; TI provides a rich set of audio and video codecs running on DSP. There is a significant software architecture change since the Maemo 2, where the DSP Gateway was a component serving directly a number of multimedia application components, replaced recently by the TI’s DSP bridge in Maemo 5, now becoming integral to OpenMax IL; DSP bridge is not visible to applications directly and the overall application complexity has been reduced. OpenMax provides an unified interface for those TI codecs and the GStreamer built-in execution threading alleviate the application complexity.

It seems that the Maemo multimedia architecture moved into the right direction.

Linux kernel development – Some insight on the ecosystem of the commons, and motives

October 1, 2009

Linux story is not just about technology development, it is also what it means for a community and what the business is becoming.  Linux kernel grew under a new deal of a collaborative effort investment and sharing the technological return; somehow a rebellious mood to push back against the exclusionary and closed systems. Overall it is a major paradigm shift how a business is conduct because this is a project that demonstrates that cooperation can be useful in developing platforms.

There is an interesting talk of Yochai Benkler on the new open-source economics having his thesis that huge cost of  developing a product will ultimately lead to a social production with the ownership of the capital largely distributed is different to the well known methods (market and governmental ). Furthermore Benkler says in his Coase’s Penguin, or Linux and the Nature of the Firm paper:

In this paper I explain that while free software is highly visible, it is in fact only one example of a much broader social-economic phenomenon. I suggest that we are seeing is the broad and deep emergence of a new, third mode of production in the digitally networked environment. I call this mode “commons-based peer-production,” to distinguish it from the property- and contract-based models of firms and markets. Its central characteristic is that groups of individuals successfully collaborate on large-scale projects following a diverse cluster of motivational drives and social signals, rather than either market prices or managerial commands.

Thanks to Alun Williams I found an interesting 2009 report on Linux Kernel Development revealing facts on “How Fast it is Going, Who is Doing It, What They are Doing, and Who is Sponsoring It”

The top five individual companies sponsoring Linux kernel contributions include:
* 12.3% Red Hat
* 7.6% IBM
* 7.6% Novell
* 5.3% Intel
* 2.4% Oracle

WHY COMPANIES SUPPORT LINUX KERNEL DEVELOPMENT
The list of companies participating in Linux kernel development includes many of the most
successful technology firms in existence. None of these companies are supporting Linux
development as an act of charity; in each case, these companies find that improving the kernel
helps them to be more competitive in their markets. Some examples:
•     Companies like IBM, Intel, SGI, MIPS, Freescale, HP, Fujitsu, etc. are all working to ensure that Linux
runs well on their hardware. That, in turn, makes their offerings more attractive to Linux users, resulting
in increased sales.
•     Distributors like Red Hat, Novell, and MontaVista have a clear interest in making Linux as capable as it can
be. Though these firms compete strongly with each other for customers, they all work together to make the
Linux kernel better.
•     Companies like Sony, Nokia, and Samsung ship Linux as a component of products like video cameras,
television sets, and mobile telephones. Working with the development process helps these companies
ensure that Linux will continue to be a solid base for their products in the future.
•     Companies which are not in the information technology business can still find working with Linux
beneficial. The 2.6.25 kernel included an implementation of the PF_CAN network protocol which was
contributed by Volkswagen. 2.6.30 had a patch from Quantum Controls BV, which makes navigational
devices for yachts. These companies find Linux to be a solid platform upon which to build their products;
they contribute to the kernel to help ensure that Linux continues to meet their needs into the future. No
other operating system gives this power to influence future development to its users.
There are a number of good reasons for companies to support the Linux kernel. As a result, Linux has a broad
base of support which is not dependent on any single company. Even if the largest contributor were to cease
participation tomorrow, the Linux kernel would remain on a solid footing with a large and active development
community.

It took personal volunteering until gained weight and height, into becoming an attractor factor. Quite our days  a snowball effect. Why? There is the resultant of rising cost of design of adding more and more complex platform features and the price squeeze which will lead commercial companies to rally with the open source phenomena as the last is less driven by the market.

On this token there is an interesting position in Collaboration is the way out of a crisis, says TSMC – IEF 2009 which reflects the mood to reinvent of the industries:


“It has to be made more profitable”, said Marced, “and it can only be done by collaboration. We have to make sure that the whole industry makes more money.”

Marced argued that collaboration reduces waste and shares investment while individual efforts lead to redundant initiatives and heavier investment.

There is also the 2008 revision for those interested in some sort of history snapshot reference of the Linux kernel development.

Robustness – a succes factor

September 30, 2009

One success factor of the Internet is carried by the content of the originator of the Internet Protocol Jon Postel recommendation:
“In general, an implementation must be conservative in its sending behaviour, and liberal in its receiving behaviour. That is, it must be careful to send well-formed datagrams, but must accept any datagram that it can interpret.”

This recommendation is generalized in a common sense Robustness principle that stays unequivocally within the cooperative spirit (of playing nice): “Be conservative in what you do; be liberal in what you accept from others”.

Technology – paraphrasing Clausevitz

September 30, 2009

Von Clausevitz uses the bold statement “Der Krieg ist eine bloße Fortsetzung der Politik mit anderen Mitteln” – war is merely a continuation of politics (with different means). Technology can be paraphrased being a continuation of the business.

The applied technical solutions are sponsored with financial means for financial return. There are standards, stakeholders, active and passive players, and wars. There are not only the technical merits that will impose a winner solution, the entire business context will tell, and in certain cases even the political regulation will come to play a role. The success stories are many times mystified, there are nothing else than personal merits, alignments of the stars and of many persons interest.

Software development cost, some measurements and available references

August 26, 2009

I got a few significant references on some of the major software platforms developments. Although there are a many themes that are interesting, but this time I am focusing strictly on the estimated development cost. For example Vista development cost is estimated in 2006 to be about 10 bilion USD, and the estimated total development cost of a Linux distribution to be 10.8 billion USD

The first comments that came to my mind: this is a lot of money! It is just difficult to justify such effort.

All the above are mammoth projects. What about smaller scale projects? Is any way to get a feeling what would be a metrics for a given project? The most handy study material is related to open source projects and there are a number of websites that provides metrics for such open sources projects:

  1. Ohloh and its project search page
  2. Koders and its project search page
  3. Krugle and its project search page
  4. Codase and its search page
  5. Merobase and its search page
  6. JExamples and its search page

To satisfy my intellectual curiosity I have been checking the GStreamer (a multimedia framework) metrics provided by Ohloh and Koders. There are a number of common sense questions that comes up once that a multimedia framework is considered. What is the cost of it? Would be build in house, purchased or open source? What are the legal liabilities? The GStreamer home page provides limited information to such questions, however the code is available for study for gathering more information.

For the software licenses structure and programming languages distribution and usage for this project the Ohloh analysis is providing the following information:

49 files
2 files
Language Code Lines Comment Lines Comment Ratio Blank Lines Total Lines
C 742,710 171,976 18.8% 174,728 1,089,414
XML 124,289 1,124 0.9% 1,678 127,091
C++ 22,364 9,922 30.7% 5,743 38,029
Python 18,885 2,708 12.5% 3,341 24,934
C# 18,022 2,589 12.6% 4,203 24,814
Scheme 13,167 296 2.2% 1,981 15,444
Automake 10,540 1,098 9.4% 2,780 14,418
Autoconf 5,221 1,140 17.9% 1,171 7,532
Perl 4,652 450 8.8% 771 5,873
shell script 3,397 730 17.7% 643 4,770
HTML 2,724 1 0.0% 7 2,732
Objective C 1,624 291 15.2% 508 2,423
Assembly 1,273 301 19.1% 236 1,810
XSL Transformation 1,209 67 5.3% 188 1,464
Make 67 4 5.6% 15 86
cmake 21 0 0.0% 7 28
CSS 13 0 0.0% 0 13

Development Cost for multimedia  plugins codecs is estimated to be 1.1 mil USD (as provided by Koders analyze), however this is not a real life case and I am expecting the costs to be higher. I would guess it is is based on the Constructive Cost Model (COCOMO).

$1,102,910
Assumptions
Lines of code: // 220,582
Person months (PM): 220.58
Functions required: 100.0%
Effort per KLOC: 1.00  PM
Labor Cost/Month: $5000

An interesting complementary view is provided by Coverty architecture library. The Coverty Architecture Analyzer tool uses information gathered during the build of a codebase to create a comprehensive list of interdependencies in the code and to generate diagrams like the shown below.

gstreamer0.10-1

Having some skin in the project

August 16, 2009

I remember my awe as a child when I have been traversing the Anghel Saligny‘s famous bridge. This bridge was build in 1890 and it was the longest bridge in Europe at that time,  along with technical achievements its value stays foremost in its strategic fasten of the country after its war of independence. After a century this bridge is considered  to be in top 10 most beautiful European bridges.

The bridge daring thrown forth is equal by its builder warranty, his life. The bridge was inaugurated on 26 September 1895 and as a test on the opening, Anghel Saligny stayed with his workers on a boat under the bridge while a convoy of 15 locomotives sped at 85 km/h.

I have to put things in perspective, there are engineering failures. There are professional licensing practices, even symbolic iron ring.

There is always the moment of truth: to stand under the  capstone as it is lowered into place, to be held to that accounting (I like Ruth Malan’s drawing). Anghel Saligny hold himself through this ancient roman ritual, a different stance to what the profane “just another job” might be. This ritual becoming a matter of life or death turns to hold the commitment true and the success measurable.

How is your project for you?

Principles of X and awareness of the temperance

June 13, 2009

I have been advocating in my organization for many months now for principles similar of Windows X. I wished reading earlier such principles, this is just a matter of chance and maturing process to recognize such realities; perhaps I have my teachers to instil such intuitive awareness of the temperance hard acquired. or applied festina lente wisdom of the software development strategy.

In 1984, Bob Scheifler and Jim Gettys set out the early principles of X:

Do not add new functionality unless an implementor cannot complete a real application without it.
It is as important to decide what a system is not as to decide what it is. Do not serve all the world’s needs; rather, make the system extensible so that additional needs can be met in an upwardly compatible fashion.
The only thing worse than generalizing from one example is generalizing from no examples at all.
If a problem is not completely understood, it is probably best to provide no solution at all.
If you can get 90 percent of the desired effect for 10 percent of the work, use the simpler solution. (See also Worse is better.)
Isolate complexity as much as possible.
Provide mechanism rather than policy. In particular, place user interface policy in the clients’ hands.
The first principle was modified during the design of X11 to: “Do not add new functionality unless you know of some real application that will require it.”

Wabi-Sabi or appreciation of the imperfection

April 18, 2009

It is fascinating reading now about wabi-sabi ,  in the midst of recession.

“It (wabi-sabi) nurtures all that is authentic by acknowledging three simple realities: nothing lasts, nothing is finished, and nothing is perfect.”

“From an engineering or design point of view, “wabi” may be interpreted as the imperfect quality of any object, due to inevitable limitations in design and construction/manufacture especially with respect to unpredictable or changing usage conditions; then “sabi” could be interpreted as the aspect of imperfect reliability, or limited mortality of any object, hence the etymological connection with the Japanese word sabi, to rust.”

Philippe Kruchten measures the architect likeness against his tolerance to imperfection: “The life of a successful software architect is a long series of suboptimal decisions often made in the dark and under pressure. A perfectionist who spends a lot of time on issues would not be appropriate for the job.” Beware of perfectionism.

There is freshness in the impermanence.  Life spring of the ephemera.


Follow

Get every new post delivered to your Inbox.