This article is inspired by Udi’s post Non-functional Architectural Woes.
“This is how the business has been done for decades and will continue to be done for decades more” (Udi Dahan 2010)

As we build enterprise systems we are confronted with continuous change in the business requirements while the business as a whole remains the same as time goes by.

In a previous post i was investigating the possibility to indentify and cover the entire scope of the project using fractal theory. Based on the fact that scope of a project is discovered as we and are constructing the system, a method for uniformly (in terms of distribution) discovery of new parts of project scope would be appreciated.

One might notice that business objectives resembles to its business area, but are also somehow particular. The more you add businesses objectives together the more they look closer to the whole industry pattern. The more you dive into one’s business speciffic objectives, the more you find differences from the industry though keeping an resemblance to the whole. Makes me think again to fractal theory. The attached movie shows how a mathematical figure (the Mandelbrot set) is zoomed in and shows us details about it’s composition and resemblances of the initial picture.

As Udi says, and I kind of agree, the architectural pillars we should be interested in discovering while building an application should be close related to the functional requirements, more specifically business objectives. Decomposing the business objectives into smaller objectives (specific to the particular business and not the the whole) is quite hard.

It is not hard to decompose business objective into smaller ones because we don’t know how, it is hard because we have no clear knowledge on how to identify the real valuable objectives and to cover all of them. We should seek the method for covering all, the method for identifying the processes valuable, all-in-one the method (the fractal function as one might say). And if this method is applied over and over it might guarantee that we are able to find the all the most valuable objectives which if implemented might lead us to a stable business architecture.

You might say that agile methods cover this by iterating and clarifying objectives as the software evolves, whereas Waterfall methods rely on well documented living documents. Both strive to complete the business objectives.

One method, which I can guarantee to work if applied over and over, is to read and comment what other great guys have to say about things you are trying to discover, to be inspired by them and to constantly learn about the targeted business domain.

I watched a nice presentation at InfoQ of John Seddon about Lean Services. He makes a valuable point about identifying costs not in activity but in the process.

Some key points John mades in re-thinking lean services:

1. Do not apply same principles from manufacturing to services

2. Study your process and follow a piece of work from entrance to exit (value work and wasted work)

3. Study demand and see which is predictable and address it using another system

4. Identify system's conditions for creating waste, not activities performed by people

5. Change is emerging, something you never plan for

6. Putting control in the hand of the workers give you more control than you ever had

7. Never manage with targets, never manage with other arbitrary measures unless you're going over a clif

8. Use measures that derive from purpose and put them in the hand of the workers

Both inspirational and controversial I might say.

More resources about him, including podcasts can be found here. 

Hope it helps. 

If you’re interested in means of improving your performance, and you search on the net, you cannot miss Kanban. The concept is very simple and I belive easy to implement. While I haven’t yet tried it myself, I searched for some software which will allow me to track the cards in the different swimlanes.

I have found a nice hosted solution at AgileZen which judging by their presentation movies is quite an impressive piece of work. Listen to an episode of Hanselminutes if you want a piece of the history of this application and the technique as well.

Another simple implementation of a Kanban dashboard is the One-Html-File which is straightforward and simple to understand for a beginner. So I thought to combine this nice idea of one-file dashboard (mainly a javascript page) with a blog site inorder to have a storage behind the board.

The concept is :

1. 1      Create a blog site for each kanban project (eg: http://demokanban.blogetery.com/)
2. 2      For each swimline in your process define acategory in the blog
3. 3.      For each kanban card we shall create a post onthe blog (http://demokanban.blogetery.com/2009/12/27/s1-integrate-sms-payment/) and select a category where to post it.

In order to display a Kanban board I wrote a simple javascript page which reads the RSS feed of the blog and creates a visual representation of the cards. Note that the script provided can be used with any blog as long as it follows the RSS format and follows the above concept.

You can find bellow 9 steps to transform a simple bloggingsharepoint site into a fully functional Kanban borad.

Step 1: Create ablog site on a sharepoint machine.

Step 3: Createthe posts and assign them to each category you choose.

Step 7: Use windows explorer view to edit the HTML file andto change the URL property in the javascript to point to your RSS address ofthe sharepoint blog. You can find this bi right clicking on the small RSS icon   on the first page of the blog.

The address should look like this:

jquery.js (55.91 kb)

kanban.htm (2.38 kb)

I just want to mention a nice presentation about REST and Winows Communication Foundation. REST is about standard HTTP methods in order to perform basic operations. It is easy and accessible to all programming languages.

Read it here.

V-ati intrebat vreodata ce se intampla cu programatorii care imbatranesc? Exista pe undeva un cimitir al programatorilor unde acestia se pot duce linistiti sa moara precum elefantii care simt ca li se apropie sfarsitul? 
Oare ce mai inseamna sa fii programator in ziua de azi? Se observa o tendinta tot mai accentuata de a crea noi metode de dezvoltare software astfel incat sa nu fie nevoie de cine stie ce cunostinte de programare, ci mai mult de imbinare de functionalitati deja existente (traiasca "copy&paste"-ul). Aceasta tendinta este una oarecum normala din punctul de vedere al managementului unei firme de IT, care vrea sa iasa pe piata cu produse adaptate fiecarui client intr-un timp cat mai scurt. Toate bune si frumoase, dar ce se intampla cu programatorii? Devin ei oare niste mici robotei care nu fac altceva decat sa arunce intr-un designer de DSL niste obiecte si totul e gata? Daca l-ati intreba pe seful meu, v-ar spune ca asta e tendinta, sa nu se mai scrie cod, ci sa se modeleze entitati de business. Dar noi suntem programatori, nu analisti de business. 
O alta categorie de programatori este formata din cei care scriu framework-ul folosit de toti ceilalti dezvoltatori din cadrul unei organizatii. Acolo chiar e nevoie de programatori adevarati, altfel calitatea framework-ului rezultat lasa mult de dorit. Trebuie sa fie niste programatori foarte experimentati, care sa stapaneasca foarte bine atat conceptele programarii orientate obiect, cat si pattern-uri de design. 
Dar sa revenim la prima intrebare: ce optiuni are un programator care vrea sa "avanseze"?Am auzit destui colegi de-ai mei de facultate care au zis ca e cazul sa faca o schimbare in cariera, ca doar "nu o sa ramana programatori toata viata". Ca si cand ar fi ceva rau. Majoritatea s-au facut project manageri (da, stiu, ce fac oamenii astia exact? :D ), altii pur si simplu au renuntat la industria IT si acum activeaza in cu totul alte domenii.  
O alta categorie este cea a programatorilor care vor sa devina arhitecti software. Cu toate astea putina lume stie exact ce ar trebui sa faca un arhitect software. Cum adica "propune solutii tehnice"? Din ce am mai citit despre arhitectura software, nu pare a fi la indemana oricui. Pe langa faptul ca trebuie sa ai o experienta destul de bogata pe partea de dezvoltare, sa fi lucrat pe multe si variate proiecte, trebuie sa fii la curent cu tot ce e nou in domeniu. Putini pot face asta, poate doar cei pasionati. Ma uitam zilele trecute pe niste anunturi de angajare pe o astfel de pozitie (US, nu Romania, unde chiar exista o piata pentru arhitecti software). Lasand la o parte diversitatea de cerinte pentru un asemenea post (inca o dovada ca fiecare intelege ce vrea prin arhitect software), trebuia sa ai, printre altele, minim 7-10 ani experienta in dezvoltarea de aplicatii pentru Windows in C++. 10 ani! Oare cati din programatorii pe care ii cunosc se pot incadra in astfel de cerinte? Cred ca niciunul. Si atunci, ce sanse ar avea un programator bunicel (nu exceptional) sa devina arhitect? 
Microsoft a lansat de ceva vreme un program de certificare pentru arhitecti (Microsoft Certified Architect Program). Obtinerea acestei certificari nu se poate face in mod traditional (dai unul/mai multe examene si devii arhitect), ci este un proces destul de laborios in care trebuie sa fii audiat de un consiliu de specialisti care, pe baza experientei tale si a interviului propriu-zis iti pot acorda sau nu titlul de arhitect. Se pare ca si cei de la MS sunt de parere ca nu oricine poate fi arhitect…  

In concluzie, ce poate face un programator atunci cand simte ca incepe sa se plafoneze? Optiunile par oarecum limitate. Este trist sa vezi ca a fi programator in ziua de azi se rezuma de fapt doar la a folosi niste tool-uri create de altii, tool-uri care transforma un programator intr-un end-user mai rasarit, cu vagi cunostinte de programare, dar care, fiind intrebat de prieteni cu ce sa ocupa, raspunde mandru "sunt programator". Cand intalnesti astfel de oameni, parca nu iti mai vine sa zici ca si tu esti programator, deja magia a disparut. Asta da moarte a pasiunii…

Wikipedia cu toate neajunsurile ei a fost clar un succes. Da are o multime de greseli in articole (dar si Britannica are desi este editata numai de experti asa cum se poate vedea de aici), da are mereu probleme de vandalism insa este din ce in ce mai populara si a reusit sa reziste desi i s-a prevazut de multe ori sfarsitul. 

De curand google a lansat un nou serviciu (da inca unul) care are ca tinta cam aceeasi nisa ca wikipedia. Nu, nu se numeste googlepedia, se numeste knol. Deocamdata are pagini create de experti insa tocmai a fost deschisa catre public si oricine va putea scrie articole. Noutate consta in faptul ca autorii vor primi ceva bani pentru articolele postate (prin adsense) si va exista si un sistem de ranking.

Acum, de ce are nevoie google sa lanseze un wikipedia killer? Pai unul din motive ar fi ca multe pagini din wikipedia au rank mai mare decat propriile pagini. Cea mai buna dovata? Pai, chiar pagina knol apare in cautari mai sus in wikipedia decat pagina de start knol. Si la urma urmei de ce nu, google a facut o afacere din vanzarea de publictate si acum o extinde pe oriunde poate, chiar si prin Yahoo dupa cate s-a auzit recent. Ramane de vazut daca calitatea articolelor va fi sau nu mai buna decat cea din wikipedia, si daca posibilitatea de a castiga bani nu se va transforma intr-un scop in sine (cateva click-uri pe ratingul articolelor concurente poate aduce un articol mai slab calitativ in top).

Ceea ce e clar e ca viitorul *pediilor e online mai ales ca recent chiar si britannica si-a deschis portile pentru creearea de articole de catre comunitate.

I am very happy as I just received the 7 edition of the architecture journal.

Many thanks to the distribution services as they can reach Romania with this one.