I was demonstrating a POC I wrote to one of my colleagues and I showed him one of the integration demo where I have a two console application - a producer and a consumer who communicate by WCF. He was surprised to see  I get two separate console windows running from within Visual Studio.

So just in case you don't know that as well, all you need to do is to go to the solution properties (Right click on the solution->Properties) and under "Startup project" select "Multiple Startup project".
You can even decide which projects will run with a debugger and which won't :)

 

CrossTalk, the journal of defense software just published its Aug. 2008 issue. Which, incidentally is its 20th anniversary issue.
This issue includes a couple of very interesting articles one is called "Good Old Advice" by Alistair Cockburn and the other is called "What Have 20 Years Accomplished and What Is Left to Accomplish in the Next 20 Years?" by Gerry Weinberg.
Cockburn explains very eloquently something I also wrote about a year ago that the ideas and lessons expressed in literature of yore are not just valid today but they drive home the points of the "coolest" ideas we have today. Alistair does that by demonstrating how the principles behind the agile manifesto builds on the works of Fred Brooks, Barry Boehm, TomDemarko, Gerry Weinberg and many others.
We have known for decades that is is all about people , users, communications between them. Alistair summarize his article as follows (emphasis mine):

"

I derived the four values of the Agile Manifesto from much older, recognized, and highly reliable articles. The point I wish to make is that the authors of the Agile Manifesto did not throw out all previous experience as they wrote it. On the contrary, what they did was cherry-pick four of the most important issues from among hundreds. The appropriateness of their selection is seconded by decades of prior experience and data, as evidenced by the numerous articles referenced in this article.

For decades, we have learned, documented – and ignored – the same lessons:

• Attend to the individuals and their interactions.
• Put the mercilessness of running software to good use – write, and learn from the writing.
• Get inside the heads of your users and customers, and get them on your side.
• Plan coarse-grained long term and fine-grained short term, and find a way to replan quickly – because you’ll have to.

And, finally:

• Do not believe in any single process or methodology because each works only in a particular and limited context.

Those who do not learn from history are doomed to repeat it. Let’s stop pretending we don’t know everything and let’s stop repeating painful history by following this good, old advice."

Weinberg writes a short retrospective of the last 20 years. Here are some interesting quotes (again emphasis mine):

Individual managers, however, have certainly improved. The good news is that we now have many more excellent managers who can mentor new managers. The bad news is that because the field has grown so much, there simply are not enough experienced managers to go around. We still see people abused or poorly used by their managers. All of this in spite of the fact that we have much more information about how to work with people in software development – information that, sadly, is frequently ignored. Too many managers have failed to learn that the world will not end due to a late delivery or a defect in production. Nor have they learned to relax, breathe, learn from their mistakes, and try again.

and

The idea of certification is only one of the management myths that has not changed in a generation. We still have an excess of heroic environments, often leading to death march projects. Many managers still maintain the fallacious perception that quality can be tested into slapdash software. Some still try to develop software without being bothered by potential users of that software. And some still believe that process models are the answer to all of our problems.

These are the things I notice on my pessimistic days. On my optimistic days, I notice more managers realizing that it is the people who make a difference, that they can hire talent, but then must also build the relationships to build a team. Quite a few organizations are now using process models successfully, but as only one of the tools providing information for informed cultural changes to their software community.

Though looking from different angles, both articles somehow hash the same ideas like 'work iteratively", "b e wary of magic or single processes" etc. I do believe that what underlines both these articles and, indeed, software development itself is that at the end of the day software is developed by the people and for the people and we should not allow ourselves to forget it.

---

*with pardon to Abe for the misqoute
 

Unless you've been living under a rock, you probably already heard about the MS offer to acquire Yahoo. While it is Microsoft who is poised to acquire Yahoo (Microhoo) it seems that it is part of the greater move of Microsoft towards moving into Internet based service - all the "live" initiatives along with the "Software + Services" moniker.
I tend to agree with Nicholas Carr who recently published an article in the Financial Times where he talks about how Gates leaving MS marks the end of the desktop era. In fact looking for the above mentioned reference I saw another article Carr wrote for Forbes where he says it even more bluntly

"One important message is this: Software is becoming a media business. The Net is not only a universal medium, a distribution channel for words, sounds and images. It is also turning into a universal computer--the machine we use to run software and store data."

You might also want to check out  a presentation a few of my colleagues  and myself has prepared about half a year ago where we talk about the same phenomena - Called the "Future of Home Computing" (5.5Mb).


In this sense the Microsoft - Yahoo merger (if it will follow through) will result in Yahoosoft a company which is focused more on the internet aspects rather than the more traditional (some would say legacy) desktop aspects of Microsoft.

It is also interesting to note in this sense that while winning the web search (and the related ad-revenue) is something Microsoft is very interested in.  The eyes of Microsoft (and Google for that matter) are on the next battlefield - mobile search. While there are something like 305 Million broadband subscribers worldwide the number of mobile phones sold just in the last quarter of 2007 was larger (334 Millions) and the total of mobile phones worldwide is in the billions... An added bonus here is that Google is yet to take over this market (thought it of course moving in that direction with things like the android platform and location based search and services)

 

I've made a minor enhancement to the site a couple of days ago. I've decided against using the static and hard to maintain blog-roll (I currently have about 250 feeds, some of which are aggregators and linkblogs. )
Instead, I've added a the more dynamic and up-to-date  "What I am reading" section, which lists interesting (to me anyway) posts, articles, presentation etc. from other blogs and or sites. I've also made it available as a feed.

 

Not the usual topic for this blog, but it may save you a few hours of trying to find what went wrong with your office 2007.
I was opening word 2007 to try to edit a document when I suddenly noticed that the mouse doesn't work in the editor window. I could click the ribbon, buttons and menu but as I said I couldn't mark any text or click in the editing area. Not to mention that Word crashed everytime I tried to close it.

Naturally, the office diagnostic didn't find anything wrong so there I went trying reparing, uninstalling stuff I installed in the last few days, blaming the anti-virus, Vista SP1 RC and whatnot.

 I finally found the answer in http://support.microsoft.com/default.aspx/kb/921541 . The kb article suggest several options. Basically all I had to do is delete HKEY_CURRENT_USER\Software\Microsoft Office\12.0\Word\Options\Data and let Word rebuild it.

As the kb article says " If Word starts and works correctly, you have resolved the problem" :) (and saved yourself a few hours)

 

PaperLnx develops an advanced visual search solution for mobile handsets based on computer vision and image understanding technologies developed by Rafael. PaperLnx solves the cumbersome web surfing experience on mobile handsets by enabling end users to send captured images from their mobiles to retrieve relevant information for the object photographed.

We now have few open positions (in Israel) for the following profiles:

 Senior Developer

We are looking for a highly motivated, resourceful and intelligent developer. Good interpersonal and communication skills will be very appreciated. A Team player. Broad thinking and problem solving capabilities are also desired.

• At least 5 years of server side development with thorough understanding of Object Oriented principled and  understanding of architectural styles and design patterns.
• Experience in multithreading and in distributed systems.
• .NET/Ruby experience
• Integration with C++ components
• Experience with O/R Mappers such as nHibernate/ActiveRecord etc.
• Video processing experience/ familiarity with video related protocols (H.324m, H.323 etc.)  a plus
• Web experience (AJAX, CSS, ASP.NET) a plus
  
• Mobile Internet backend development a big advantage
• Understanding of architectural constraints (security, availability, scalability etc.) for internet scale platforms a big advantage
• Team leading skills – an advantage.

 Algorithms Developer

We are looking for an experienced algorithm developer or an outstanding MSC graduate with image processing concentration. A team-player interested in joining a young and dynamic firm.

• Experience developing image processing algorithms using Matlab
• Computer vision/Image processing experience a must
• Experience transitioning algorithms from Matlab to software (C++/C/C#/F#)  a big plus
• Familiarity with video compression protocols a plus
• experience with performance tuning and scaling optimizations
  

 
If you think you qualify and want to join a promising startup you can send your CV  or call  me at 052-3331027
 

 

In a post called "Ignorance vs. Negligence", Ayende blows some steam off on some of the so called "professionals" that he met along the way. You know ...those with a fancy title that don't know jack and design some of the nightmares we see from time to time (go read his post, I'll wait, promise). I see this myself all the time:

• The senior security expert who recommended something which isn't supported by the platform
• The senior architect who throw the system down to hell by basing all the system on a clunky asynchronous solutions that should only be used by a tiny portion of the application.
• The geniuses that built this wonderful code generator that generated code with so many dependencies and singletons that made the solution unusable
• The chief architect that created this wonderful performance hog, and then kept poking around to make sure we don't fix it too much.
• The architect that partitioned a distributed solution based on functions - so that each and every business process has visit go through all the tiers and components. The solution made the everything more complicated by few orders of magnitude (scale, synchronization, availability, performance what not)
• The architect that designed his own distributed transaction mechanism (basically duplicating COM+) - naturally with less than satisfactory results...
  

Etc.
Ayende says

"They all have a few things in common, they represent themselves as experts, senior, knowledgeable people. In all those cases, they have actively acted to harm the business they were working for, by action, inaction or misaction

I have no issue with people not knowing any better, but I do expect people that ought to know better to... actually do know better."

I don't think that this is negligence involved here- I think all of these people want to do the right thing, they probably believe they are right. They were probably also pretty good at their jobs which is what got them to their current position.
What they didn't learn is to "know that they don't know". This is a hard lesson to learn. I think hope I learned my lesson after the first time I tried to distribute a (naive) solution I was so proud of. At least, in my case, I stayed around for enough time to both see the results and learn how to fix the problem.
I think not staying around for enough time is one of the problems that causes this ignorance -  since starting out things usually look good enough and if by the time the problem rears its ugly head you are already in a new shiny job, they you don't know better.

Another problem that causes ignorance is not looking around and learning only from your experience. For instance, I am now interviewing a lot of people, and when I ask a question like "tell me about something interesting you recently read- a book, an article, a blog anything" - I usually get blank stares. Few people tell me about an article they read that is related to a problem they had and fewer still tell me about something without a direct relation to their work.  If you don't look beyond the keyboard you will never know better. learning only from your mistakes can be problematic - especially if we also consider the previous point (people don't stay around)

Ignorance is bliss they say, but I think ignorance has a lot to do with the crappy systems we see all around us and its one of the reasons writing software stays more of an art than a science or craft.

 

I received a number of inquires regarding PaperLnx following the help we rendered to Yediot in enhancing the quality of the video of Yitzhak Rabin's assassination (The link is to a site in Hebrew).

Our business is not video enhancement per se. What we do is use this and other similar proprietary technologies to provide a form of visual search for pictures taken on mobile phone cameras. "surfing" on a mobile phone is not a good user experience, typing URLs and search terms is cumbersome and lengthy. Using this image understanding capabilities we enable end-users to get at the relevant multi-media content for the object they are interested in (the object in the picture taken). This type of application are called "physical world connection" solutions. Naturally we are not alone in this space, but think that the technology we have gives us a competitive edge in the robustness of  our solution.

We are now at the stage where we the technology is pretty solid and we "only" need to turn this into a product, which is as I mentioned in another post, why we are looking for a few good men (and/or women) to join us.

 

Finally, I've quit my current position - to take a new job as VP R&D at (what I think is) a very promising start-up called PaperLnx.
 
In a nutshell we are going to build few solution in the "physical world connection". What's "phisical world connection" you ask? Well, here's a nice definition from "The Pondering Primate":

"When a display was added to the first mobile phone, a new media was created. Since then, Internet connection and a camera have been added that have created a new way to interact with the physical world.

Soon speech recognition will allow an additional way to browse the physical world too.

Every physical object will have a physical world hyperlink

That means every physical object will allow connection to a designated website and the mobile phone with it's psychical world browser will be able to surf the "real world", the physical one."

As can be expected from the "long tail" curve we are not alone in this space (the link above has a nice list of other companies).  However I think we have a competative edge... :)

Incidentally, I am looking for "a few good men" (or women) to join us. We need both developer and QA positions:

Senior Server Developer

We are looking for a highly motivated, resourceful and intelligent developer. Good interpersonal and communication skills will be very appreciated. A Team player. Broad thinking and problem solving capabilities are also desired.

• At least 5 years of server side development with thorough understanding of Object Oriented principled and  understanding of architectural styles and design patterns.
• Experience in multithreading and in distributed systems.
• .NET/Ruby experience
• Integration with C++ components
• Experience with O/R Mappers such as nHibernate/ActiveRecord etc.
• Video processing experience/ familiarity with video related protocols (H.324m, H.323 etc.)  a plus
• Mobile Internet backend development a big advantage
• Understanding of architectural constraints (security, availability, scalability etc.) for internet scale platforms a big advantage
• Team leading skills – an advantage.

Senior Web Developer

We are looking for a highly motivated, resourceful and intelligent developer. Good interpersonal and communication skills will be very appreciated. A Team player. Broad thinking and problem solving capabilities are also desired.

• 3 years web development experience is a must, 5+ years experience a big plus.
• Experience with web-related technologies Javascript, HTML, CSS, AJAX
• .Net/Ruby experience.
• Understanding of Object Oriented principles and REST architectural style.
• Experience with web MVC frameworks like MonoRail/RoR
• Experience with O/R Mappers such as nHibernate/ActiveRecord etc.
• Familiarity with SQL 2005/mySQL. Knowledge of SQL an advantage. 
• OLAP, datamart experience an advantage
•  Team leading skills – an advantage.

QA Person

We are looking for a highly motivated, creative and intelligent QA person. Good interpersonal and communication skills will be very appreciated. A Team player.

• Experience testing WEB  applications.
• 
  
• -Testing creativity. Understanding of Test related methodologies
• -Experience designing and controlling all the stages of the project's life cycle.
• -Experience with test environments such as FIT, FITNESSE or at least other automated tools- advantage.
• -Knowledge of SQL an advantage.
• -Dot-Net/Ruby/Python/Powershell - advantage.
• - Cellular web testing experience a big advantage
• -At least 2 years experience in the field

If you think you qualify, located in Israel and you are interested in changing  the world :), you can send your CV to me
 

Having just read Doron's Yaacoby's post on some of the insights he got  from reading Tom & Lister's Peopleware, I'd thought I'd repost a couple of posts I wrote about a year ago in my Dr. Dobb's Journal blog (with a few edits):

I just finished reading Software Conflict 2.0: The Art and Science of Software Engineering, by Robert L. Glass.

This is a reprint (with few new retrospective additions) of his 1990 book. While the technology mentioned in the book is outdated, many of the author's ideas and views are still valid. The book is a collection of short articles on various subjects, and one of the more interesting articles is about the cognitive side of design.

Glass explains that research done showed that design includes the (obvious) steps of understanding the problem, decomposing it into goals and objects etc. The essence of design, however, are the mental steps taken by designers:

1. They construct a mental model of proposed solution
2. They mentally execute the model (i.e. simulate the model to see if it solves the problem)
3. If the model isn't good enough (e.g., too simple) replay the simulation to find what wrong and remodel
4. Repeat 1-3 until the model seems to solve the problem

Glass also said that people tend to start with a model that worked on a similar problem and that good designers perform this process extremely fast. As I was thinking how one can train himself to get better at performing this task, it occurred to me that I heard something similar  somewhere... While not the exact process this is very reminiscent of TDD - only TDD makes the process explicit. In a way we can say that TDD will not only help make your design better it would also  trains you to design better altogether.

Robert's book has several other views still relevant today. While it can seem odd that a 16-years old book contains relevant thoughts looking at my bookshelf I see there are quite a few other books (some of which are event older) which contain essential information and brilliant ideas that are still very relevant today. Here are just a few examples:

• Peopleware Second Edition by Tom Demarco and Timothy Lister (Second edition 1999, original 1987). Development should be centered on people and not on methods

• The Mythical Man-Month: 20th Anniversary Edition by Fred Brooks (20th anniversary edition 1995, original 1974). "No silver bullet" don't just add people to a late project it will only slow it down and many more.

• Code Complete by Steve McConnell (Second Edition 2004, original 1993). A great book on coding.
  
  
• An Introduction to General Systems Thinking (Silver Anniversary Edition) by Gerald M. Weinberg (silver Anniversary Edition 2001, original 1975). Observations on thinking processes
  
  
• About Face and About Face 2.0 (3.0 edition 2007, 2.0 Edition 2003, original 1995). UI mistakes and guidance, the second edition also details a scenario based approach to user experience design.
  

Getting back to TDD or at least the idea of test first. It seems (via Rob Keefer pomiet blog)  Gerald Weinberg talked about it more than 35 years ago in  Psychology of Computer Programming :

"By pursuing this test example to the point where he understands the problem, he will not only learn the one thing he did not know, but perhaps will learn others as well, for test programs such as this are often better learning instruments than are production programs.

As a matter of good practice, the test program should be constructed before the 'fix' is made to the production program. In the first place, there will be an all too human tendency to forget about the problem once the production program is working correctly, so we must impose a little discipline on ourselves. Possibly more important, however, is the chance that by the mere act of constructing the test case we shall discover the problem."

Anyway, with so much good advice lying around for years (11-40+) and the fact that only about 30% of the projects are successful (on-time;on budget; on scope) I think one question we should all ask ourselves is -- don't we ever learn?

 

Yesterday, I finally finished all the chores and obligations for my MSc. in Information Technology.

Phew, what a relief - especially considering the last semester (summer) was very loaded as I studied 3 days a week .
Anyway, at least now I should have more time to work on my book (Chapter 6 was starting to feel a little neglected :)).

 

dasBlog 2.0 is out which is good news for those hosting with  medium trust like (yeah Go Daddy...). dasBlog 2.0 finally allows me to use some of of the new features like Tag Cloud, Akismet integrations, native feedburner integration instead of the hack I did earlier etc. So I immediately upgraded

I've took the chance to also move to  a nicer theme (thanks to John Forsythe and Jon Stovall for adding this theme to dasBlog). Lastly I've also moved the URI naming  to PascalCase URIs instead of the ugly GUID Permalinks. The old Permalink type URIs are of course still available as well (Even with my limited command of the English language, I've managed to figure out the idea behind the "Perma" in Permalink)

(PS  Technorati blog claim:Technorati Profile- you can disregard this line otherwise)

 

Just got back from Chicago, where I attended Architecture & Design World. The event was great. it had many interesting talks and sessions  which I'll blog about in  few of the following posts (Also I'll upload the slides from my sessions later this week). One session however, was very disappointing for me, Ivar Jacobson's Keynote on "Next Generation Process with Essential Modeling".

I was really looking forward for this keynote; After all Ivar is one of the "Three Amigos", father of use cases and all. Also I had the chance to attend a couple of his presentations several years ago and he had a very interesting and convincing appearances at those times. Unfortunetly this session was nothing like those previous events.
Ivar talked about his new methodology. The basic idea behind the essential software process is (in my opinion) correct. Instead of big bang prescribed processes - it is better to tailor a process from a set of practices to get something that fits the organization/project at hand. It might be a little unnerving to hear this from one of the people who brought (upon) us the RUP, but, I guess it is good to see people who are constantly learning.

The problem was that while the main idea can be summed up in one line (see above) Ivar went on fro the better part of the hour to explain how cool it was that his base set of practices comes on a set of que cards that can be sorted and arranged. He also went on to explain the game board (or something to that effect) where you can lay different cards to both describe your current process as well as the bunch of practices you want to use for your future process.
If that wasn't enough, when he (briefly) shown us the cards that talk about the architecture and architecture description practices the advice/guidance there was very mediocre and general
I expected much more from someone of the stature of Ivar Jacobson.
On the up-side this was only one keynote and the other sessions I listened to where much better - as I already said, I'll blog about few of them in upcoming posts.

 

Coming back from vacation I saw that Jeff Atwood (coding horror) wrote a post on "rethinking design patterns"
a few days ago. Jeff criticizes the GoF design patterns book
Jeff says his two main grips with the book are

1. Design patterns are a form of complexity. As with all complexity, I'd rather see developers focus on simpler solutions before going straight to a complex recipe of design patterns.
2. If you find yourself frequently writing a bunch of boilerplate design pattern code to deal with a "recurring design problem", that's not good engineering-- it's a sign that your language is fundamentally broken.

I agree that these can be a problem with using design patterns in general and the GoF ones in particular. I would add to this that I think that using design patterns just to be able to say you've used them is very wrond as well (this may sound obvious - but I have seen organizations where this was encouraged).

I don't think however, any of those problems are problems with the patterns themselves. This is not to say that the GoF book is perfect.Looking back at the GoF book I think that it isn't clear of problems. For instance, I don't think all the patterns stand the test of time. The most prominent example for that is the Singleton pattern, which I hardly recommend using these days. Singletons are problematic for testing and  create a tight coupling for a specific instance. There are better ways to create a mono-instance if that's what you need (I think others have posted about it in the past - but I can post about it separately if needed)
Also, newer languages sometimes provide better ways to tackle some of the design patterns solutions - see for example a recent post by Alex Miller where he talks about an alternative for Template Method.
I can even say, that not all the patterns are that useful (Flyweight comes to mind as an example).

Nevertheless, I still think that the GoF book is one of the most important books in computer science. First it is a seminal work which introduced the patterns thinking into software development. Today we have literally hundreds of patterns on all subjects and technologies. I think it is a very good think since the looking at a problem from a pattern perspective gives us more depth and understanding on both the problem and the solutions vs. other ways I've seen.
Even in itself, the GoF book is great, since many of the patterns are very valuable and can help us solve real problems. we just need to keep in mind that the sample implementation in the book is just that - sample. There can be more than one way to code a pattern and still gain the benefits (these are "design" patterns not "coding" patterns). A few weeks ago, someone asked a question on the visitor pattern in one of the forums I monitor. The guy needed to add an additional parameter to the Visit method and asked if it wasn't a violation of the pattern. I told him that there isn't such a thing as "violating a design pattern". The patterns are a means to an end not some coding codex we should keep. I think, that if we treat the design patterns as pieces of knowledge
rather then a holly script, they can really help avoid some stupid mistakes.

Thus, at the end of the day, I still think the Gof book is required reading for any new developer. But hey, that's just my .2 cents :)

 

A couple of quick  observations following the Events and temporal coupling post

Events, Current data and aggregated data all have Time-to-live aspects.

• Events value usually diminishes over time until the TTL reaches
• Current data usually have a constant value while their TTL lasts (until a new value is the current data) - unless we are talking about version data which is a  component of or a step  in the direction of aggregated data.
• Aggregated data  has the longest TTL, it is interesting to note that its value increases over time

Also while the Current data TTL is determined by the producer both Events and Aggregated data TTLs are determined by consumers

Yeah, I know these are not not earth shattering observations but I still think they are  interesting
 

 

It was more than 10 years ago that I got my first MVP award from Microsoft (I was probably the first Israeli MVP, because few years later Microsoft Israel awarded what they said werethe first Israeli MVP awards... :) )
Anyway, now, for the forth time, I got awarded again - this time it is in the Solution Architect category -
Thanks

 

I've been working in Rafael for a total of 5 years now and I guess my tenure here is nearing its end.  The latest company-wide reorg has brought with it the end of the biometric product line (or maybe just its evolution into something I don't really like - it isn't completely clear yet, but since I don't like both option it doesn't rally matters).

I am checking several possibilities of joining one of the consulting companies here in Israel - none of the options has fully matured as of yet but I believe that in the next month or so something will be finalized - meanwhile I am also open for other options (my CV is on the about page - hint, hint :) ).

In any event, between the book, DDJ, InfoQ and looking for a new job (not to mention my family) I sure have have my hands full - I guess now I understand why they say "may you live in interesting times" is an old Chinese curse :)

 

Yesterday I attended an SOA governance presentation by Brent Carlson. The presentation was basically an updated version of an article he authored in 2006 "SOA Governance Best Practices - Architectural, Organizational and SDLC implications" As a  tool vendor Brent has a lot of focus on the governance processes which I don't completely agree with (I prefer Jim Coplien's organizational patterns approach - see my post from last week). I also think the reuse figures he cites (registration required) are a little optimistic common place for what I consider the right granularity for services.
He also made a few points I  strongly agree with

• Brent talked about difference between the needs of run-time service repository (e.g. UDDI or an ESB) and a development time one. You need to address the services and their interactions during the development and you need to do that in a way that would be easy for the development teams. For example, one thing you want to log is usage, who is using the services since that will let you perform impact analysis when you have to make a change
  
• Building an SOA for an organization is an iterative process not a "big-bang" effort. This means you can't do just top-down design. you need to be pragmatic and also roll out working services.

The reason for this post however is the insight Brent gave regarding treating services as products rather than applications

Treating Services as products is  important because even if you don't believe that the SOA initiative should be  an iterative process once the move is  finished you would have quite a few services deployed in your organization. These services would integrate and interact with other services - some of which outside of your organization. You would also want to capitalize on flexibility claim that SOA makes and adapt your services to the changing business needs.
The challenges you face regarding updating and upgrading  functionality , anticipating consumer's needs, allowing consumers to get used to changes etc. are exactly the challenges product management techniques and principles come to answer

Treating services as products means a lot of things. let's look at a few examples: For one, it means predictable release cycles services like products get updated over time you want service users to be able to cope with this changes. Predictable release cycles means they can get organized in advance. Another aspect is the emphasis on backward compatibility e.g. orderly deprecation of features and version management,.One other thing  is introducing a "product manager". someone whose responsibility is to interact with customers, and potential customers, understand their needs and build a release road map for the services.

You might be used to doing some of that with applications   but thinking about services an products makes all this more explicit and that in itself is also important.

 

Yesterday I attended Jim Coplien's presentation on "Organizational Patterns - a Key for Agile Systems Development". Overall I think It was a very good presentation. Jim makes a few interesting claims, some of which are controversial within both in the traditional and the agile spaces
Few examples

• Process guidance (ISOs etc.) doesn't work - roles are stabler than processes, processes always change.
• Jim says that in order to make a change you need to make it at the organizational structure level. The processes will then support these changes
  
• TDD is evil - it is just an re-incarnation of bottom-up procedural design. It is better to follow "Design by contract"
• He says XP is not a good methodology (He thinks SCRUM is good)
• etc.

Additionally he talked about some of the organizational patterns he and Neil Harrison discovered studying organizations for more than a decade. You can  read the Top ten patterns on his site.

Jim covered 2 patterns that are related to software architecture: Architect controls product and Architect also Implements
Architect controls Product basically says that you should have an architect and that she should oversee that the direction of the project is flowing in the right direction.

Architect also implements - this pattern says that in order for the architect to broaden her leadership without sacrificing depth and pragmatics she must also participate in the implementation (beyond advising and communicating). Jim gave the example of the development of Borland's Quatro pro for windows in 1993 where the team's architect had a daily meeting (akin to scrum stand-ups) for synchronization and would then go and code with the developers. The Quatro pro team had 4 architects out of 12 persons that made the team.If a third of the development team is architect I'd say he is right -  My experience, however with most organizations I see is that you hardly have one architect per  project (sometimes you only have one for several projects). In these cases I hardly see the architect writing production code as part of the team since she would not have time to fulfill her architectural responsibilities. She must know how to code though and she must be able to prove her designs in code or be able to offer a candidate implementation if needed (I also wrote about that in the past see "Should architect's code" part 1, part 2, part 3

By the way if you are located in Israel, Jim will be here for a couple of weeks and he is giving a few courses like Agile Architecture, Patterns of Agile Project Management etc. You can find more information on pacificsoft's site

 

Back in January, I took part in an architect panel that Microsoft Israel organized. The panel was led by Ron Jacobs and it featured Udi Dahan, Assaf Jacoby, Coby Cohen, Dudu Benabou and myself. A few days ago Ron edited this recoding and turned it into a podcast in his Arcast series.

The panel's focus was on lessons learned from mistakes made in past project. Ego maniac as I may be :) -- even though you don't get to hear me much in the final edited version -- I think the podcast is worth listening to, as the panel raised some interesting points. You can download the podcast here (don't worry it is in English even though it was recorded in Israel)

PS

I am the first speaker after the introduction, in case you are wondering.

 

I'll be presenting a  90 minute class on SOA Patterns on the upcoming Architecture & Design world 2007 - which will take place in Chicago on July 24-27th.
If any of you happen to be there, I'd be very happy if you drop by and say hello :)

 

 

Back in January I opined that  moving to web applications was not the optimal solution to the real problem we have/had with desktop applications which was  installation woes. What we got was a poor UI without installation problems so we (software industry) started to resolve problems like we had when we moved from  terminals to graphical UIs etc. - 
So now we have Rich Internet Applications (RIA) - using technologies like AJAX - but they suffer from other problems  which again we've already been through

Well that was the topic of the post in January. Now I've stumbled upon an interesting/amusing  twist - called Adobe Apollo
Apollo let's you, yes you've guessed it, take your RIA applications and deploy them as desktop applications.  you can now take your HTML, CSSs , AJAX scripts pack them up as a single file (AIR) and lo and behold deploy them on the desktop. You even get these nifty start menu and desktop shortcuts :)

The reason not to dismiss this a complete waste of time - is that what we actually see here is another example of a trend to convergence  web and desktop UI architectures  and programming models. I say "another" because coming from the desktop direction Microsoft is doing pretty much the same thing. WPF brings the web-programming model  with its markup (XAML) and "code-behind" concepts to the desktop as well as pushing the same model to the browser with WPF/E .

The difference between Microsoft's and Adobe's solutions is that, Adobe is coming from the web-side and, as I said, Microsoft is coming from the Desktop side - both companies are striding toward the same goal -  and what we are left with,  is yet another technology war

 

All I can say is I want one

http://cellphones.engadget.com/2007/01/09/the-apple-iphone/

 

[based on a few posts from my DDJ blog]

Implementing Business Intelligence (BI) solution on top of Service Oriented Architecture (SOA) is not a simple feat. A recent survey by Ventana Research shows that "...only one-third of respondents reported they believe their internal IT personnel have the knowledge and skills to implement BI services.". There's a good reason for that since there an inherent impedance mismatch between BI and SOA which takes some effort to overcome. The purpose of this paper is to look to explain the problem as well as look at the possible solutions.

Service-Oriented Architecture is about autonomous loosely coupled components. These traits gives you lots of benefits such as greater flexibility and agility but it also means that services have private data. Data that you don't want to expose to the outside as exposing it will decrease autonomy and increase coupling. This is why services only expose data and processes via contracts rather then exposing their internal structure.

That is all fine until you start to think about business intelligence. The cornerstone of any business intelligence initiative is gathering, collecting and consolidating data from all over the place. Once you have the data, you can use tools to analyze it, data mine it, slice, splice, aggregate, and whatnot. Traditionally BI builds on ETL (Extract, Transfer, Load) which goes directly to the database of the involved sources.

And here lies the problem: On the one hand we have services that want to keep their data private, and on the other we have a datamart or warehouse that wants that data badly.

What are our options?

• If you go with traditional ETL, you introduce coupling into your service.
  
• If you only rely on contracts that were constructed for business processes you may be missing out on important data.
  
• If you build a specific contract that exposes "all" the data you are back at the point-to-point integration -- solving point-to-point integration is one of the reason we want SOA in the first place.
  

The second option seems to be the most reasonable choice of the three -- but it also has several problems. One problem is that the BI needs to know about all the contracts. The second was already mentioned -- important data might be missing. The third problem is that the BI system need to fetch data from the services which means it may miss out on data in the intervals between request. On the other hand, too frequent requests and you can congest your network easily as well as cause DOS on your own services.

Clearly we need a fourth option

In my opinion, the best way to tackle BI in SOA is to add publication messages into the contract. By "publication messages", I mean that the service will publish its state either in a periodic manner or per event to anyone who listening. This is a service communication pattern which I call "Inversion of Communications" since it reverse the request/reply communication style which is common for SOA.

To make the solution complete, you can add additional requests/reply or request/reaction messages to allow consumers to retrieve initial snapshots. Following this approach, you get an event stream of the changes within the service in a manner that is not specific for the BI. In fact, having other services react on the event stream can increase the overall loose coupling in the system - for instance by caching results of other services

Why is this better than the other three approaches? For one , you can get a good picture of what happens within the service. However the contract is not specific for the BI and can be used by other services to cache the service state (thus increasing their own autonomy), for reporting (you can see an early draft of the aggregated reporting pattern), and for BI purposes. By working against a steady stream of events, the BI platforms can Analise treands, keep history and get the complete picture they need.

The approach above is sometimes referred to as "Event Driven Architecture" (EDA) and while I (and others) see EDA as another facet of SOA, not everyone agrees. Gartner, for instance, sees EDA as another paradigm and SOA just for request/reply, or client/server. Recently, however, they published a paper that calls the approach described here as "Advanced SOA". I tend to agree more with the "advanced SOA" definition and don't see a contradiction with EDA and the SOA definitions. We are still using the same components and the same relations only adding an additional message exchange pattern into our toolbox.

A note on implementation: If you are implementing SOA over an ESB that is rather easy to implement as most ESBs support publishing events out of the box. Using the WS* stack of protocols, you have WS-BaseNotification, WS-BrokeredNotification and WS-Topic set of standards. If you are on the REST camp, then I guess you will need to implement publish/subscribe by yourself.

Once you have event streams on the network, The BI components grab that data scrub it as much as they like and push it to their datamarts and data warehouses. However, event steams can also enable much more complex and interesting analysis of real time events and real time trend data using complex event processing (CEP) tools to get real-time business activity monitoring (BAM)

You can also get post as as a presentation down loadable from the papers section on my site or directly from here. (The download is about 3MB.)

 

Welcome to chain-letters blogsphere style. There's this on-line tag game going around, I've been watching it spiraling around on many of the blogs I read and now Udi dragged me into this as well :)

So here goes - here are 5 things you don't know about me:

1. It only took me 14 years to get my BA degree in Computer Science. I began studying in 1990 in the Technion ,quit after 2 years and only bothered to graduate when I wanted to get a Masters degree

2. I was a Microsoft Foxpro MVP for 3 years in the 90s - about half of that time I was working on completely different platforms and tools (J++ and C++ on Windows and then J2EE on Solaris).

3. first met English in fourth grade (like most other Israeli kids at that time) - by the eighth grade I read my first real book - Shogun. I took me 3-4 month to get through the 1200 pages of the book, but I've been reading English since. In fact I hardly read Hebrew anymore.

4. I learned to program on the ZX81 - I remember the joy the first time I fully used the 1K memory it had, as well as the disappointment the followed thereafter when the instructor tried to add the 16K expansion which caused the machine to reboot.

5. I used to be a hobbyist bar tender. I still have more than 70 different bottles at home, with everything from Grenadine to a 25 years old Glenmorangie. I don't mix too many drinks these days, I mostly drink the Macallan.

I don't want to stay "it" for too long :), so on to tagging some other folks: Ohad Israeli, Andrew Johnston, Tad Anderson, Nancy Folsom and Ruth Malan. You are all it

 

Roy Osherov recommended this site today - but he also urged me to write more frequently.

This is probably a good opportunity to explain how posts are divided between my 3 blogs

• First theres the blog on Dr. Dobb's Journal. This blog is published on the "Architecture & Design" section of DDJ portal. I blog there about 3 times a week. Jon (my Editor @ DDJ) prefers a steady stream of blogs over longer posts which means that I break down large subjects (like OO principles, fallacies of distributed computing and the currently running series on the Architect's soft skills) into many parts.

• The second blog is a new one on Microsoft's Israel blogs site. The aim of this site is to bring Architecture content in Hebrew to the Israeli architects (As can be imagined, most of the technical content available is in English, I thought it was important to generate some content in Hebrew as well)

• The last blog is this one. My current plan for this blog is as follows

• • Cross posting selected posts from the DDJ site
  • I am posting here complete articles made by editing and aggregating multi-part blogs posts (again such as the fallacies etc.)
  • Pointers to presentations and articles I publish
  • In the near future, I'll start posting bits of my upcoming SOA patterns book (I am currently writing chapter 3). I've already documented 8 patterns (of more than 50 patterns and about 30 anti-patters). I plan to publish here at least some of the patterns here for review (I am still crossing the t's and dotting the i's with my publisher but I expect this to be finalized soon)

so Roy, does seven (7) posts in seven days (including 3 on Ms Israel site, 3 on DDJ and this one) qualify as posting often enough? :)

 

I've added a new section on the site www.rgoarchitects.com/Papers to allow easy access to all the papers, presentations and articles I published (and will be publishing e.g. I'll add a paper on architect soft skills in a month or so etc.)

 

 

The October issue of Dr. Dobb's Journal is available and with it my article on the SPAMMED Architecture Framework .

 

 

Dr. Dobb's has begun a special (6 issues) E-Zine  called  "Dr. Dobb's Requirements Development" and I am happy to say that Issue #1 includes the first part of an article by me on the subject of use case modeling.

The issue also includes articles by Joe Marasaco (author of "Software Development Edge"), Andrew Stellman & Jenifer Geene (authors of "Applied Software Project Management") and Karl E. Wiegers (Author of "Software Requirments" 2nd edition.)

You can get the EZine by registering on www.ravenflow.com to the bi-monthly Requirement Develompment magazine

 

 

Over the last few months I've posted a series of blogs on DDJ that cover the basic Object Oriented principles (e.g. Single Responsibility Principle, Don't Repeat Yourself, Inversion of Control etc.).

I've assembled all the posts into a single whitepaper which you can get here.

Also you can download the same (plus a little more) material as a powerpoint presentation.

 

 

[Crosspost from my DDJ blog]

When talking about multi-tiered architectures, we need to remember that the tier boundary is significant. The tier boundary is where distribution happens and if you remember the "fallacies of distributed computing", you know not to take that lightly.

A tier is a physical boundary (versus an Edge in an SOA which is a logical boundary, for example) and the implications are numerous. For instance, you need to consider:

• Trust--who do you let in?
• Security--what do you send out?
• Performance--you need to serialize to pass the boundary, and remote data is expensive to fetch.
• Availability--what happens if you crash?
• Manageability--can anyone see what's your state? Help you recover?
• Temporal coupling--can you afford to make synchronous calls?
• and many similar questions.

Yet many times people think passing a tier is as simple as passing a logical layer. I should know. I made this stupid mistake more than 15 years ago in one of the first distributed systems I designed. I planned this beautiful separation of the UI controls from the business logic (I didn't know it was called "MVC" and that someone else had figured it out ages ago, so I was pretty proud of myself). When you clicked on a button you just used metadata to say that BL should catch it. I had all this wonderful "infrastructure"that handled passing the call to its destination.

But then we wanted to take this n-layer application and put the BL in an "application server" which will handle multiple clients. Oh--now we need to move events over the wire , handle calls from multiple unrelated clients, pass a lot of data back and forth, and what about security... you can imagine the fiasco.

Thus, as Niels Bohr once said, "An expert is a person who has made all the mistakes which can be made in a very narrow field." But you don't have to make the same mistakes. Just remember that a tier is a natural boundary. You know what? You should probably even want to consider it the edge of a cliff at the end of your application--and be careful not to fall down.