This is another post in the “From the Trenches” series about our research project on communicating the value of architecting within Agile development. I meant to post this earlier, but I’ve been in the trenches digging.

As Ipek Ozkaya discussed in our From the Trenches kickoff post, we are approaching our research on the value of architecture from the perspective of release planning. I am excited about this perspective because it moves the discussion of architecture’s value out of the realm of philosophy and into the realm of action and choice. As practitioners, we may talk to management and marketing and other decision makers about how valuable architecture is, and they may, in principle, agree. However, the real test of whether we’ve made the sale about architecture’s value is when the time comes to make investment choices, and that’s where release planning comes into play.

As part of our research, one of the books we reviewed is Software by Numbers by Mark Denne and Jane Cleland-Huang, published in 2004. The book has been influential in Agile circles, not so much for the specific algorithms that it contains, but for bringing the issue of value to the forefront of discussions on release planning. Here are a few of the concepts that we found particularly interesting and relevant to our project.

In Software by Numbers, Denne and Cleland-Huang coin the acronym MMF (minimum marketable feature) to represent a unit of software value creation. This concept really hit home with me, based on experiences from early in my development career. I was working on a PC product targeted toward several discrete market segments. Our team quickly discovered that to be successful, a given product release needed to have a sufficient “chunk of value” to make a discernable impact on the value perception of at least one of the target segments. A release strategy that provided just a little bit of functionality to all the segments would fail to make the required market impact.

We definitely plan to incorporate the concept of MMF into our research work. We are, however, toying with the idea of changing MMF to MRC (minimum releasable capability). Our thought is that changing “marketable” to “releasable” addresses internal IT and DoD projects that are not marketed, per se, but that still need to provide discernable value at the time of release. The thought behind changing “feature” to “capability” is that the term “feature” may be seen as having a bias toward functionality, whereas “capability” is broader in meaning and could more easily encompass the inclusion of quality attribute enhancements into a release. Any opinions on this proposed terminology would be more than appreciated, by the way.

Chapter 4 of Software by Numbers is titled “Incremental Architecture.” In this chapter, Denne and Cleland-Huang make the point that “architecture needs unambiguous traceability back to the needs of stakeholders so that the rationale behind each architectural element is well-defined.” Linking architecture to stakeholder value is not, of course, a new idea. The SEI’s architecture-centric engineering practices have focused for years on architecture as the key to enabling successful delivery of quality attribute requirements.

However, the authors of Software by Numbers consider architecture not from a technical perspective but from a financial perspective; that is, from the perspective of their “incremental funding model.”  Within this model, they propose decomposing the architecture into a set of architecture elements that can be linked to the MMFs that they support and, consequentially, factored into an incremental release strategy. This is an interesting point of view and could certainly simplify the issue of clearly apportioning architectural cost and value. However, it also raises a host of questions such as

• What exactly constitutes an architectural element? Is it a framework, a pattern, a tactic, a mechanism, an architecturally significant component such as a piece of middleware?
• What about efforts related to architectural prototyping and technology selection? How do these costs factor into architecture’s overall value proposition, and how are they apportioned to MMFs?
• How do you account for the critical mass of architectural elements that must be present in the first release and must precede the development of any MMF?

Finally, there is the topic of how to quantify value. In Software by Numbers, the authors use rigorous calculations to determine net present value (NPV), internal rate of return (IRR), and break-even time for a project. This approach is appealing in that it clearly expresses value in the language of NPV and IRR, which are typically used in funding justifications. Also, focusing on NPV and break-even time clearly highlights the issue of MMF timing and sequencing, a key consideration in incremental development and release strategies. On the other hand, the calculations are laborious and require a high (perhaps too high) degree of precision in determining the value of individual MMFs and the impact of time delays on those values. The alternative to the Software by Numbers approach would be to use value points (similar to story points) as a relative evaluation technique. Jim Highsmith discusses the use of value points in his latest book Agile Project Management.

These are some of our ideas so far. Some are fully baked and some are half-baked but we’re making progress on what I find to be a fascinating topic. Thanks for visiting us in the trenches.

Nanette Brown – SEI

Assalamoalykom,

كل سنة و انتم طيبين
Eid Adha Mubarak, and may Allah bless you and your families in shaa’ Allah,

After some quality time with family during last two weeks Eid vacation, we are back again to business.

First thing was waiting for me was a project scope statement in Arabic! A challenging task  indeed, I will let you know in a coming post how did it go, for now and for this fresh cool morning here in Dammam here is a funny article that suites early morning coffee or if you wish tea with mint and milk , enjoy.

An A-Z Guide to Being an Architect

Salam,

Other day I was hiring a dedicated server. In doubt about whether choose between windows 2003 standard or web server. I’ve chosen the standard one. It has message queuing system and I needed it so much. Then stumbled at Amazon Web Services – Then I felt myself stupid. They provide Queuing services and worse – at very cheap price.

That comes as lesson… nowadays we can just architect solutions without take into account the new approach of services in the cloud. Amazon Web Services is just a sample which provides a lots of interesting services like Storage (very cheap), scalable mysql server (not that cheap but considerable if you’re really doing business) and many others.

I know there are other service providers which in my point view still needs clarify what services they provide and what cost is going to be at end. I’ve seen some services about cloud computing which always appear to be more expensive than it should. They also miss details which makes me unable to calculate exactly what I going to need.
How I would know how much processor cycles my application is going to need in month? Still not comfortable these days, hope it get better!

Recently I started to research how to develop on .NET as I’ve been developing for JavaEE.
First thing that came to my mind as a JavaEE architect was: “Okay, IIS and ASP.NET are some of the presentation tier alternative I have for .NET but what for business tier?” or rephrasing as someone that has
been using JavaEE for a long time: “What would be the .NET EJB?”.
First thing I missed was the concept of the MDB that in .NET stack that seems to be replaced by an MSMQ message trigger.

Another major .NET difference is that even though it seems to have the concept of the VM process (as Java does) it has the concept of a shared library, or the Global Assembly Cache. If you think in terms of Java then you have to either manually replicate the jar or share them using a shared storage and having it on the classpath.

As we are on the classpath subject, .NET and its CLR seems to avoid (and limit it to J#) the concept of a ClassLoader. Although sometimes problematic, the Java concept of the ClassLoader allows very sofisticate scenarios of application composition and also for hot code generation (by the application) at runtime.

I hope this post has helped anyone in the situation as I were before and I also hope it does not sound as a comparison of which platform is better as you might guess that I sincerely know that each one has its applications, strengths and weaknesses.

A friend has a book which needs to be published. Thru the process (which is still on ) I was fortunate to see the ring-side view of all options and here are some of the details.

Publishing: This is the traditional model which still works best if your book is selected by publishers. the publishers ask for a manuscript. If they like it, they will invest in it, do everything needed, and pay the author a royality. If your book appeals to publishers, maybe this is the best way. you get professional everything – editing, marketing,media, sales etc. and your book appears in more bookshelves without you lifting a finger than you imagine. You dont have to invest money and you get royality for sold books. Unfortunately, we were out of luck so we explored options.

Self publishing: Self publishing is quite mature now both in india and worldwide. Worldwide – you have companies like Lulu. In india, you have companies like CinnamonTeal and pothi. They operate on a “print on demand” basis – which means they will print books as they are ordered – even one book. However there were several dis-advantages

1. Digital printing is most expensive. I thought Pothi’s price was quite reasonable at just over a Indian Rupee per page – even if you ordered just a single copy. This means that if you have a 200 pager book, you can sell it at 250Rs and make 35 Rs per book. Its not bad, but compared to something like 50-60 rs per book for printing when you print a 1000 copies, this does sound a lot. Actually its not that bad till you look at number 2.
2. You can only sell via their online store. It wont get listed on flipkart and indiaplaza and other online book stores. You always have an option to buy copies and list on them. Now assuming that they want 30% margin, the price of the book goes upto 350 Rs. But if you leave it at the self publisher, the buyer doesnot get discounts or free shipping. Now, they charge you a prey steep shipping costs at about Rs 50 - taking the book price upto 300 Rs if you leave it there. So I am begining to think its a pretty neat deal for niche books – but slightly expensive for popular ones ( especially when your idea of sales is bullying friends and family into buying it).  The good part is that you get something in hand immediately, no questions asked – and given the fact that it is one book at a time its not a bad deal. 
3. There is no pre-publishing ( more on that later), marketing, distribution to other stores at all. You are complely on your own. These costs may add up.

Now coming to the in-betweens. There are two options that I found out.

1) Sponsored publishing: Here you bear approximately half the cost of launching a book by the publisher [so even if the publisher is half convinced, they will go for it]. It has all the goodness of traditional publishing, and the royality you get is a bit higher, however, you start making money only after your book has sold between a 1000 to 2000 copies. This is not bad for a popular book. They promise everything – a launch, circulating it to media, getting reviews, listing it on online and offline stores via distribution channel, all logistics, inventory keeping etc. – everything. Now its upto you if you want to invest money on it, and expect returns only if the book is very popular. One of the publishers who agreed for it was Frog Books. They are very responsive.

2) Self Publishing ++ : Self publishing complaines offering traditional Printing+ Distribution: Sandeep of Blushing Pi got us this option. They offer all pre-publishing, printing, digital marketing, and distribution – most of it done via 3rd parties – but managed by them on a “a lat carte” pricing.

Now coming to a description of puublishing lifecycle as I understand it. People in industry like to divide into 3 stages (called pre and post printing or publishing depending who you talk to ):

Pre-publishing or Pre-printing : This involves completing the content – including editing etc, doing the design, and getting the files in printable format.

Publishing or Printing: Test print – proof – print.

Post publishing or post printing: including one time activities like finding distributors and ongoing tasks like Store inventory, distribute to online and offline book store. Marketing and sales are also a big part of this stage.

Pre-Publishing

Pre-publishing tasks involve

• Finalize content
• Obtaining copyright on material you are quoting:
• Prepare manuscript to circulate to publishers
• You could get agents who will take your book to publishers – for a price. Good agents could get you a long way.
• Proof Read – preferably by a different person – this is to ensure the quality of what you have written.
• Editing: get reviews and edits from a professional to increase the quality of work significantly.
• Cover design : Work with professional designers to get this. Note that it might help to have an ISBN number before you do this so that the bar code could also be generated and added.
• Preparing other illustration and graphics: For cover and for content if you need graphics, it might be a good idea to get it done from a professional.
• Foreword : you may want someone else to write it – preferably someone popular who may be able to recommend the book to many .
• Obtaining Copyrights for your book: As per laws in india, the copy right automatically happens to the author the moment the content is created. however, in case you want to go in for obtaining copyritghts – then you could register copyrights with copyrights office at http://copyright.gov.in/copyrightregistrationform.pdf. You can have a company handle copyrights for you for about Rs 5000. One of the companies who can handle it for you is Brainleague
• Getting ISBN number – you need to know the number of pages, whether its paperback or hardcover etc. before you can get an ISBN number. In India, a person can get an ISBN number on their own. If you want someone else to handle it for you – that is also possible and not very expensive.

Printing

• Digital printing: This is usually economical for upto 200 copies.
• Offset printing: This is best for over 500 copies. For between 200 to 500 copies, either could be fine.
• The material provided to printer needs to have proper typesetting. The offset printers usually bundle that service with no or minimal extra cost.

It might help to strike a deal with a distributor before you go for printing.

Post-Publishing

• Getting a distribution deal: To list your book on online bookstore or in physical bookstores, you need to have a deal with distributors. Distributors order books from you, reach them to stores. The stores typically want over 30% discount on cover price of the book, so that they can offer discounts, free shipping etc. To do that, distributors want minimum 45% off cover price. Anyway, you need to strike a deal and they are likely to ask for more - with a most likely deal between 55% to 45%.
• Inventory: you need to store books and provide them to distributors when they request for it. Its quite expensive to outsource it and it could cost 1-2% per month of book cost to store it.
• Marketing: The traditional publishers have a set of contacts of journalists who review books based on their interest. They send the books out, and a few will send out a review whether they publish it or not. Usually, unpublished comments cannot be quoted. On a slightly higher end, you could have a book launch event where you can invite journalists and a few are more likely to write about it. You can also mail the book to libraries, push it to other influential people who can talk about it, have in-store displays. The no-money option is digital marketing which is to create a blog, place links, distribute e-books ( few chapters or full book)to bloggers etc. Digital marketing takes a lot of your time but doesnt cost much money. It helps if you order listed books to send to others rather than sending copies you have as the distributors and retailers will get excited by sales and may throw in extra advertising, promotions and discounts to push the sales further.
• Direct sale: you could also sell directly via ebay or other marketplaces to earn the retailer money yourself.

I am still going thru the process and will update what I learn. Do feel free to contact me via a comment on this post if you need any details or contacts.

Hunkemoller has won the award from ING retail this year for the best on-line fulfillment. This price has been awarded by a panel of experts, instead of online votes by the users, and Hunkemoller is very proud to have won it.
Personally I take a bit of pride because I have designed and maintained the solution architecture which allows them to be successful.

Source:

ING retail price 2009 (Dutch)
Twinkle (Dutch)

Thank you Fred for mentioning it to me

OK, let’s put the brand new service provider model to some good use.

Whenever a service call reports an error I want some message box telling me about it (rather than simply swallowing it, which is the default behavior). Whenever the user does something potentially devastating I want some explicit confirmation, read message box, that he knows what he’s doing. MessageBox.Show does all I need (well, it is restricted to OK and OK/Cancel, but one can live with that). Only… these system message boxes are dull, boring, and not at all a shiny example for a Silverlight application. Enter the message box service provider…

Basic implementation of a message box service

The basic implementation will get the infrastructure up and running.

The first step is defining the service contract. Show this and that and a query method. The first (and naive) version looks like this:

The default implementation of our application extension service turned service provider (AES/SP) would use the dull system message boxes to implement that. The code is actually quite straight forward:

Now, I could demand that the app.xaml has this one (or any other service implementing my interface) registered. However, I like to be correct by default, thus my accessor will fall back on this implementation if none is registered – and I can be sure that there will always be a respective service.

All that is left is a search&replace for all calls to MessageBox.Show… E.g. to show an error:

… and to get confirmation, in this case to return a book:

And, of course, it works as expected:

Replacing the Dialog

Second act. Get rid of those dull things.

Create a new “Silverlight Child Window” and style it to look like a message box. I „borrowed“ the images from the Visual Studio Image Library (on my machine under C:\Program Files\Microsoft Visual Studio 9.0\Common7\VS2008ImageLibrary\1033\VS2008ImageLibrary\Objects\png_format\WinVista\) and simply placed all possible images in the dialog. A textbox, two buttons, that’s it. Here is the styled XAML:

Some code is needed for the initialization. The message has to be set, the correct image made visible, etc.. I could probably have done this with less coding, using some tricks and elaborate databinding. But who cares, it’s straight forward and comprehensible (unlike what I probably would have come up with).

Setting the DialogResult property also closes the dialog (sik!).

Finally I need a replacement AES/SP. The main method to show the dialog looks like this:

Great? Great! … GOT YOU! (Fell into the trap myself, actually… :-/ )

Fixing the Bug

Remember that in Silverlight everything is asynchronous? Well, everything except MessageBox.Show? And ‘everything’ includes ChildWindow.Show! Meaning my confirm method will not work this way. To overcome this I decided to pass a delegate to the dialog constructor and made sure it’s called in the OK case:

And to be able to pass the delegate I changed the existing AES as well (and the interface respectively):

Of course I had to adjust the default implementation using a messagebox:

The calling code changes respectively, passing a lambda:

Done. Now my application looks nice, even if it has to show a message box:

ANFSCD…

This endeavor served actually three purposes:

• First, I wanted/needed the feature
• Second, I wanted to see/demonstrate the service provider pattern from a user’s point of view.
• And third – as you may have noticed from some screenshots – I used this implementation to check out VS2010 beta.

A quick verdict about VS 2010 beta (not really worth a separate post)…

The core system, i.e. the shell, the C# code editor, build system, etc. feels very good. No apparent bugs, quite fast, including intellisense, and close enough to VS2008 to feel familiar. Considering that big parts of this are complete rewrites, this is quite an achievement.

The visual designer for (Silverlight) XAML works nice for user controls. Designing grids, the property pane, and other tasks, is at first glance en par with Blend, but comes in a more familiar „Visual Studio flavor“; still it feels more rich and mature than VS2008.
However, there are some notable gaps. Editing of styles and templates, animations, and visual state manager are not covered. Thus my guess is that Blend will remain a necessary complement to VS, even if one has to switch less often. BTW: Contrary to what Tim wrote, I could work with Blend on VS2010 solutions (the project that cannot be loaded is only the web project), I just refrained from manipulating my project files with Blend.

Other areas I touched briefly have been less satisfying. IntelliTrace didn’t work, but I didn’t spend too much time on that. The architecture and modeling area for example has changed, but is by no means bug free (to the point of “not yet usable”). The profiler has evolved, but IMO still lacks what DevPartner offered nearly 10 years ago: a decent call graph.

Oh, one bright spot for any dev lead: code analysis (FxCop) rules are now maintained in separate files, projects reference these files by name.

Anyway, I have been using VS2010 beta since I installed it and was never compelled to switch back to VS2008. I’m going to have to reinstall my machine anytime soon, and I’m planning on going along with VS2010 beta, not installing VS2008 at all.

That’s all for now folks,
AJ.NET

Software applications are based on layers and the communication between them, so the main task in the design of an application architecture will be the identification and creation of layers and then to specify a communication language and set the rules and guidelines of the interaction between these layers.
To start the design of an application architecture, the architect should keep in mind the following points:

• Separation of concerns
• Clearness in the communication rules between layers.
• Implementation of loose coupling between layers using abstraction (Interface)
• Separation of component between logical layers (UI-Business-..)
• Keeping the data format consistent within a layer or component

If we really take into consideration these points, the application will be easily extensible and testable, and its components will be clearly identifiable and reusable.

One of the big features in Accpac 6 is SData support. What is SData? SData is a web services protocol based on REST. What is REST? REST is a web services protocol that is very popular among Internet companies. There are basically two main competing standards for web services. One is SOAP which is promoted by Microsoft, Oracle and IBM; this is a fairly heavy duty protocol which requires a fair bit of infrastructure (which is provided by the companies promoting this protocol). The other is REST which was invented as a University Research project and basically uses existing Web Technologies such as HTTP and RSS to implement a web services protocol. The nice thing about REST is that it doesn’t require any extra middleware. You are basically doing everything via standard web URLs. The infrastructure that supports this is basically just the standard Internet. SData is just an extension to REST, similar to Google’s GData which is also based on REST. REST protocols are used by Google, Amazon, eBay, Yahoo and all the main Internet companies. Gartner estimates that 75% of web services in use on the Internet are REST based. REST/SData also provides a standard mechanism for performing CRUD (create, read, update, delete) on all records.

From Accpac, every Accpac View (or Business Logic Object) will be exposed via SData. This provides third party ISVs a complete, efficient Web Services interface to communicate to Accpac with. Also all Sage applications are being made SData aware, meaning that all Sage applications can manipulate SData Web Services (or feeds). For instance here is some Accpac A/R Customer and G/L Account data displayed within a Sage CRM Dashboard using SData.

From a simple wizard you can select any Accpac SData feed and once you’ve chosen a feed, you can select which columns you wish to display. Additionally Sage CRM and Accpac will be converting to use SData for our integration needs, this transition will occur over several versions of both products. In the same way you will be able to access CRM data from Accpac using SData.

All the new Sage ERP Accpac 6 screens are written entirely using SData. This means the screen can access any Accpac Views via SData, but additionally they can access any SData feeds from any product. In Accpac 5.x, the screen controls were mapped via datasource controls to views and view fields. This was great, but it limited you to only connecting our standard controls to fields in Views developed in our SDK. Now that the controls are mapped to a standards based SData fields, it means they will be able to be connected easily to much more data than just Accapc data. Look for other Sage products to start providing SData interfaces in their coming versions.

Sage is publishing SData as a publicly available standard. You can read all about it at: http://sdata.sage.com/.

8HSH59MCDDGM

Are you looking for a good book on Architecture? Then, Microsoft Application Architecture Guide, 2nd Edition is a ‘must-read’. Though it is tuned to working with Microsoft technologies, much of topics covered have larger relevance. What I like about this book, compared to other books on software architecture, is practical relevance and ease of application

Hats off to Microsoft for bringing architecture from the elite glass house to developers’ workspace!

Hace unos meses Telehealth Solutions una empresa Inglesa ubicada en Watford, lanzo CardioPod, un producto en el que venimos trabajando hace ya unos cuantos meses. El mismo permite calcular el riesgo cardio-vascular de un paciente mediante la realización de una serie de test y cuestionarios.

Por ahora el producto los están usando las tres principales servicios de medicina de inglaterra, pero esperamos que en el proximo año se sumen muchas mas.

Les dejo algunos links con articulos sobre el producto:

http://www.news-medical.net/news/20090624/Telehealth-Solutions-launches-CardioPod-for-NHS-Health-Check.aspx

http://www.european-hospital.com/en/article/6058.html

http://www.ehiprimarycare.com/news/4990/cardiopod_launched_at_nhs_camden

http://scottishhealthcare.co.uk/78/edinburgh-pharmacist-cardiopod/

Philips Research and Embedded System Institute (ESI) in the Netherlands have launched this survey of system architects and managers to understand architecture decision making.

In the Sage ERP Accpac 5.x series of product, all screen definitions were part of the Visual Basic programs that made up each user screen. The only way to get at these screen definitions was to embed the OCX for that screen in a VB program or VBA macro and then manipulate the screen programatically. With Accpac 6.0, we wanted to make many screen customizations way easier. The solution was to separate the screen definition from the User Interface program. In Accpac 6.0 each screen is defined in an XML file that contains all the layout information. This screen can be edited in a Visual Screen Designer that is part of the product, or since XML is just a text file, it can be edited in a standard text or XML editor. For that matter the screen can be generated from another program. The definition of the screen layout file (xsd file) is available and the format is completely open.

In Accpac 5.x, we saved a lot of programming time by binding the individual UI elements to datasources. This meant that an edit control was actually attached to a View field via its properties in the VB form designer. Then the control would be data aware and handle setting its data into the view and retrieving updated data from the View. In this way, no programming was required for most of the forms on the screen. We have exactly the same concept in Sage ERP Accpac 6.x. Only each control is bound to a field with in an SData feed and that SData feed could theoretically come from any Sage application that provides SData feeds or from any other application that has adopted the open SData format. Thus again no programming is required for most fields on the form.

Then we have gone one step further and provided standard actions that can be attached to controls in the layout. In Accpac 5.x you had to code all the logic that happened when a button was pressed. In Accpac 6.x we provide standard actions, so for instance you can attach a save action to the save button which will perform the save operation on the configured SData feed. This way we can develop simple forms with navigation, save, new and delete operations, with no programming. The declarative layout actually produces a complete running program can run with no additional code. Many of the Accpac setup and other simple screens can be developed this way, greatly speeding the development of Accpac 6.x.

The layouts for Accpac 6 are quite different from the screens in Accpac 5.x. For one thing all controls were placed on 5.x screens at specific x,y co-ordinates. In Accpac 6, all layout is handled by browser document object model layout nodes. Nothing is specified in x,y coordinates, you just specify which controls line up and how and then the process is dynamic depending on the length and size of the text. This is a great benefit when translating into languages that take more space like Spanish since the form will automatically adjust to the longer text. When running a right to left language like Arabic, it’s even smart enough to be able to re-arrange all the controls into a right to left ordering. All this is just functionality built into every browser and something we gladly don’t have to worry about.

These are just some of the new things that declarative layouts are bringing to Sage ERP Accpac 6.0A. This will really be a strong and flexible foundation to develop on.

In September I presented on the foundations of MapReduce and MapReduce applications at the St. Louis Lambda Lounge.

It always surprises me how simple the MapReduce algorithm is and how few people really understand it. After the talk I had multiple people approach me and say “I have had elements of MapReduce on my applications for a long time and didn’t know it.”

Here are my slides from the talk.

Is Google Wave a flop? I do not think so!

I have received an invite for Google Wave. Just started playing around with it. I am very much impressed with Google Wave.

What interests me is that the paradigm shift in communication; pretty much close to typical discussion. Discussions, in general, are not linear. It aligns very closely with human thought process and group activities like discussion. A good discussion, though would be centered on a topic, would also cover variety of related topics as well

Will it replace current forms like emails and IMs? It may not. Just as emails have not removed regular mail service.

Applications? Plenty. I would use it to record my own thought process and learning. I would also use it in any group activity, including software development.

Will it be a success? Well, there is more to success in the market than just realization of need and a good product. Critical mass, financial muscle, marketing push, competition and many other factors too play a major role

I am waiting for getting all my contacts into Google Wave. At this point, I am constrained by the number of invites that I can send

I found out the Code Generation conference. Happens in Europe and sounds to be nice. They talk about code Generation and Model-Driven Software Development. The community says that the event has a strong practical focus and an emphasis on sharing experiences and knowledge and I hope to be there next year.

Note: This is part of a series, you can find the related posts here…

The last post used the new Application Extension Services (AES for short) to include security into the application. This time I’m going to take AES one step further, laying out yet another piece of basic infrastructure.

As a quick recap: An AES is a simple class, implementing a simple interface (IApplicationService) and optionally another one (IApplicationLifetimeAware). It is then registered by the developer via the app.xaml. SL3 instantiates the AES at runtime and calls the respective callback methods on said interfaces, including StartService, StopService, and others. The recommended way to use these services is to maintain a static property and reference the class accordingly.

Basically AES solve one problem: How do I extend the global application class, without actually replacing it, i.e. without providing a derived class?

The problem here is that many libraries need some kind of global anchor and in the past, tool developers often chose to provide this by subclassing the next available central artifact (e.g. the page class or the application). And the next tool developer doing the same rendered those two libraries mutually exclusive, just by employing an adverse implementation strategy.

However, SL3 solves only the providing part of the equation, the part related to the application class and the instantiation of the AES. But look again at the consumer code:

Following the recommendations, I get singleton access to some object. Worse, the calling code is directly and tightly coupled to the AES class. But frankly, do I need SL3 to implement a singleton? Certainly not. Then why use AES in the first place?

What I’d love is to have the consumer code depend on some service (read interface), not on the actual implementation. And the ability to swap those services in and out, without affecting the caller. Matter of fact, the calling code doesn’t and shouldn’t care whether I use a SecurityServiceThatGetsItsInformationFromTheServer or a SecurityServiceThatGetsItsInformationFromWindowsAzure (or google account, open id, whatever).

If I could get that, AES would become a very valuable feature… . 

Introducing Service Providers

OK, what the calling code needs is some service in terms of a contract, say ISecurityService, that it can ask for. And the same is true for any crosscutting concern, such as error reporting, tracing, caching, you name it. And actually .NET has already addressed this need with the service provider pattern. This pattern has been used for example in WF (e.g. to introduce workflow instance persistence), and quite extensively in the Visual Studio design time infrastructure.

OK, I can hear you crying out DI. And the chorus chanting Unity or Ninject (to name just two that support SL). But think again. Would you (or rather a library developer) mandate a specific DI container without reason? And you can always wire your pet container into this pattern by providing a IFactory service using whatever container you like. After all, the pattern handles access to services, not instantiation of them. (Which is what AES does, but again, Microsoft chose not to provide a fully fledged DI container…)

What do I need to make this approach tick? I need a GetService method that iterates all AES – they are available via Application.ApplicationLifetimeObjects. And I need something to attach this method to. Using an extension method I can actually attach it to the application class:

The method iterates all AES, checks whether one implements the requested (interface) type. It also checks whether any AES itself follows the pattern and implements IServiceProvider, and respectively forwards the request if it does. (This allows me to build up a chain of providers.)

That’s it. Long talk, short implementation, all set

Reimplementing the SecurityService

Now I need the rework the SecurityService and the calling code to comply with the pattern. The service interface is simple enough:

And my revised security service looks like this:

The base class ApplicationServiceBase implements the two interfaces with respective empty virtual methods, thus I only had to overwrite StartService. Aside from some reformatting the most notable difference with the previous implementation is the absence of the static Current property to access the service instance at runtime. I also renamed the class to reflect what it does. Since the calling code won’t refer to that name any more, this is now feasible.

Accessing the service at runtime is done – drum roll please – using the service provider pattern. This (admittedly not exactly nice) code can be hidden in a simple static property, adding a little convenience. I did this with a class that provides a static property, but also allows calling an extension method on the Application class:

BTW: Wouldn’t it be nice to have extension properties that I could attach to the application class…?

And the calling code, i.e. the access to the user object changes to:

Now the calling code is completely decoupled from the actual implementation of the security service, meaning I could replace it without affecting the calling code.

A look ahead: Building on the pattern

There are several use cases for this pattern that I will employ (they may or may not be addressed in later posts, but at least this list should give you some ideas):

• Last chance exception handling: A service will react to the unhandled exception event and gather context information. It will then use another service to report the error.
• Message boxes: I will need message boxes for errors, information, and confirmation. The system MessageBox is however somewhat dull. A service will cover that and a later implementation will replace the boring system dialogs with nice and shiny replacements.
• Logging and tracing: At some point I will have to tackle these demands.
• …

I’m sure you can think of other examples, like navigation with parameter passing, global state, caching, …. Anyway, I think this is motivation enough to roll out some additional infrastructure.

As a side note: Actually I had a completely homegrown implementation of this pattern for SL2. When SL3 came out and offered AES I quickly jumped on the bandwagon and threw away most of that code. If only Microsoft had not stopped one step short of my needs… . I’d rather have the platform support that out-of-the-box. And given the simplicity of the remaining implementation this shouldn’t have been too much of an issue.

That’s all for now folks,
AJ.NET

Lean software development demands too much automation. Of course, the idea is to make more with less and have higher quality until delivering software functionalities most important for the business. This path is hard, really hard. You’ll probably have to rethink all your gained knowledge and start developed a solid wisdom through research. Constantly looking new ways to do what you do today and improve what you think you need not.

Not every IT company will really benefit of Lean Thinking. Such style demand too much research and intellectual work which results will came along the way. You need to keep traces so to really understand the intangible results. This is expense, and you may give up in the very beginning.

I believe that the worse thing still the daily operation activities along low budget and unprepared managerial staff. People are too involved with day-to-day problems and stop everything aiming rethink their work in such advanced way can be a laborious process that can simply never happen!

Any way… I would like to present the Automated Software Design Research Group. This group explores new ways to develop software. They have a lot of academic papers (Dissertations and Theses) which can simply be applied to your life. Even if you not in Lean or Agile environment.
See ya..

Deciding not to architect is an architectural decision. Postponing key architectural decisions while focusing on iteration-at-a-time development and customer-visible features negatively affects the success of large-scale projects. On the other hand, indulging in analysis paralysis in search of the best architecture that will sustain the system for its entire lifespan has the same effect. This is a reality that both the agile and architecture communities have accepted, especially in the context of large projects. But given that neither little-to-no-architecture nor big-up-front-architecture delivers the desired results to project stakeholders, what is the solution?

Communicating the value of architecting within agile development is a year-long project that Nanette Brown, Robert Nord, and I have just begun at the SEI with the goal of better understanding and measuring where the sweet spot is for just enough architecting to support agility in the context of large projects. Understanding how architecture-related tasks and features appear in iteration and release planning is an essential aspect of finding the right balance. We observe, as have many others such as Jim Highsmith in the latest edition of Agile Project Management, that foregoing planning in the haste of development does not necessarily equate with agility. Customer-visible features come to be because of the underlying organization of the software. Every system has an architecture, explicitly designed or not. The separation of architecture, code, and features might aid in project management, yet the reality is that they are not clearly separable.

Architecture can focus planning, backlog management, and refactoring. It can help prioritize features that are architecturally significant. However, this requires eliciting architecture-related features, assigning value and cost to them, and having mechanisms that treat customer-visible features simultaneously with architectural features based on their dependencies. Philippe Kruchten describes these concepts and their relationship to each other quite clearly with the metaphor of painting. We are also collaborating with him and his team at the University of British Columbia.

We often get asked at the SEI, “What are you currently working on?” On one hand, I’m glad that people care. On the other hand, I feel responsible that, in the search for solutions, we should not overlook the simple and the obvious. Being overly protective of ideas can lead to overthinking and overanalyzing, common pitfalls in any project, and contrary to agility: open communication, frequent feedback, courage, and simplicity.

In response, we have decided in this project to practice the principles of agility. We will make frequent posts here talking about what we are currently thinking, what we have read that we thought was valuable, what we applied, and what we think will not work as we progress on this project.

Ipek Ozkaya – SEI

Rushing things is bad.  You are in a hurry to get to the supermarket just to find, once you are there, that you forgot the shopping list at home. When developing applications, rushing things without a proper background design leads to spaghetti code. You module A depends on B, B depends on C, and C depends on A. There is some hidden master components, the sums of all of them, which is hard to notice, maintain and reuse.

Dependency structure matrix can help you find those harmful dependencies. The key on this tool is the way the important data is presented to the user (you). Matrix organization let’s you easily spot dependencies, where graphs tend to be hard to visualize.

This is one of the tools we are currently using to deliver high quality software to our clients. You can find more info in the following links:

http://sdg.csail.mit.edu/pubs/2005/oopsla05-dsm.pdf

http://www.theserverside.net/tt/articles/showarticle.tss?id=ControllingDependencies

RIA Services (new home page) is a collection of tools and libraries for making Rich Internet Applications, especially line of business applications, easier to develop.  Brad Abrams did a great presentation of RIA Services at MIX 2009 that touches on querying, validation, authentication, and how to share logic between the server and client sides.  Brad also has a huge series of articles (26 as I write this) on using Silverlight and RIA Services to build a realistic application.

I love the concept of RIA Services.  Brad and his team have done a fantastic job of identifying the critical issues for LOB systems and have the right idea to simplify those common data access tasks through the whole pipeline from database to UI controls, using libraries, Visual Studio tooling, or whatever it takes to get the job done.

So before I lay down some heavy criticism of RIA Services, take into consideration that it’s still a CTP and that my scenario pushes the boundaries of what was likely conceived of for this product, at least for such an early stage.

Shared Data Model with WPF & Silverlight Clients

The cause of so much of my grief with RIA Services has been my need to share a data model, and access to a shared database, across WPF as well as Silverlight client applications.  Within the constraints of this situation, I keep running into problem after problem while trying to use RIA Services productively.

The intuitive thing to do is: define a single data model project that compiles to a single assembly, and then reference that in my Silverlight and non-Silverlight projects.  This would be a 100% full-fidelity shared data model.  As long as the code I wrote was a subset of both Silverlight and normal .NET Frameworks (an intersection), we could share identical types and write complex validation and model manipulation logic, all without having to constrain ourselves to work within the limitations of a convoluted code generation scheme.  Back when I wrote Compact Framework applications, I did this with great success despite the platform gap, and I didn’t have anything like RIA Services to help.

Incompatible Assemblies

Part of the problem arises because Silverlight assemblies are incompatible with non-Silverlight assemblies.  A lot of what RIA Services is doing is trying to find a way around this limitation: picking up attributes and code files from one project and inserting that code into the Silverlight project with a build action.  This Visual Studio “magic” has been criticized for its weakness in dealing with multiple-solution systems where Visual Studio can’t update the client because it’s not loaded, and I’ve heard there’s work being done to address this, but for my current needs, this magic aspect of it isn’t a problem.  The specifics of how it works, however, are.

Different Data Access APIs

Accessing entities requires a different API in Silverlight via RiaContextBase versus ObjectContext elsewhere.  Complex logic in the model (for validation and other actions against the model) requires access to other entities and therefore access to the current object context, but the context APIs for Silverlight and WPF are very different.  Part of this has to do with Silverlight’s inability to make synchronous calls to the server.

In significantly large systems that I build, I use validation logic such as “this entity is valid if it’s pointing to an entity of a different type that contains a PropertyX value of Y”.  One of my tables stores a tree of data, so I have methods for loading entire subtrees and ensuring that no circular references exist.  For these kinds of tasks, I need access to the data context in basic validation methods.  When I delete nodes from a tree, I need to delete child nodes, so update logic is part of the model that needs to be the same in every client.  I don’t want to define that multiple times for multiple clients.  I like to program very DRY.  In other words, I find myself in need of a shared model.

RIA Services doesn’t provide anything like type equivalence for a shared model, however.  Data model classes in Silverlight inherit from Entity, but EntityObject in WPF.  In the RIA Services domain context, we RaiseDataMemberChanged, but in a normal EF object context, we need to ReportPropertyChanged.  In WPF, I can call MyEntity.Load(MergeOption.PreserveChanges), but in Silverlight there’s no Load method on the entity and no MergeOption enum.  In WPF I can query against context.SomeEntitySet, but in Silverlight you would query against context.GetSomeEntitySetQuery() and then execute the query with another method call.

This chasm of disparity makes all but the simplest shared model logic impractical and frustrating.  The code generation technique, though good in principle, keeps getting in the way.  For example, I have both parameterless and parameterized constructors in my entity classes.  This works great in my WPF client, but when this code is synchronized to my Silverlight client, I get an error because the Silverlight-side entity class is generated in two parts: in the hidden partial class, a parameterless constructor is generated which calls partial method OnCreated; and in the visible partial class, the constructor method I defined on the server is dumped into another file, so I have duplicate constructors.  If I remove the parameterless constructor from the server side, I get an error because my entity class requires a parameterless constructor (and defining a non-default constructor effectively removes the default one from the resulting type unless it’s explicitly defined).  I thought I could define the partial method OnCreated and put my construction logic in there, but the partial method is only defined on the client side.  That means sharing construction logic consists of copying and pasting the OnCreated method across the various clients—far from an ideal solution.

Entity Data Model Required to be in Web Project

Another strategy I attempted was to define the .edmx file and my partial class extensions in a class library, and then reference that from the web project.  I could define the LinqToEntitiesDomainService<MyDataContext>, but sharing entity class code (by generating code in the Silverlight project) isn’t possible unless the .edmx file and partial class extensions are defined in the web project itself.  This would mean that my WPF client would have to reference a web project for data access, which by itself seems wrong.  (Or making a copy of the data model, which is worse.)  It would be better for the WPF client to talk to the same domain service as the Silverlight client, but RIA Services doesn’t give you an option to link that web project to a non-Silverlight project, so again I ran into a brick wall.

So Don’t Do That

The kind of advice I’m getting for this is, “so don’t do that”.  In other words, don’t write complex validation logic in the model or otherwise try to access the data context; don’t write parameterized constructors; don’t aim for 100% type fidelity across all endpoints of a system; don’t try to share data models with Silverlight and non-Silverlight projects, etc.  But I see the potential for RIA Services, so I have to push for these things unless I hear really convincing arguments against them (or compelling alternatives).

Conclusion

The fact that there are different data contexts and data item definitions within those contexts imposes a burden on the developer to use different techniques for each environment, and creates challenges for centralizing data model logic and reusing equivalent logic across different kinds of clients.  My gut feeling is that RIA Services in its current form has some fundamental design flaws that will need to be addressed, taking into consideration systems with a mix of Silverlight, WPF, and other clients, before it becomes a truly robust data access platform.

OK, back down from vacation – proud about the accomplishment and perhaps with some new perspectives. It really makes you think about the effects of the financial crisis if you happen to work primarily for banks… . Well.

Note: This is part of a series, you can find the related posts here…

The last post (pre-Kili ) provided me with the necessary infrastructure to address the next topic: application security.

Silverlight is “secure by design”. It runs in a sandbox, only allowing restricted access to the local machine. Regarding server calls it supports HTTPS and windows authentication for intranets, it restricts URL access and allows only calls to servers explicitly opted in for. From a .NET perspective it has a changed programming model, no longer supporting CAS, but a more simple model that takes the restrictions into account that are already in place. It has the well-known interfaces IPrincipal and IIdentity in place, yet no implementation and no anchor to ask for them, like HttpContext.User in web applications.

Silverlight is so secure, it doesn’t even tell you, who you are.

From a purely technical perspective this is perfectly in order. The services I call are running on the server and it’s their job to make sure no one does something or gets to know something he isn’t entitled to.
On the other hand, many intranet applications need to know the user name, if only to display it. And they need the permissions granted to the user to hide buttons, menu entries or make edit fields read only – none of that for actual security reasons (the server would take care that the user couldn’t do any harm, anyway), but to improve the user experience, not letting him do things and telling him afterwards that he has had no permission to do what he did in the first place.

User and roles are available at the server at the ASP.NET runtime, and one “only” needs to make it available to the client. Matter of fact, ASP.NET provides the necessary service implementation readily available. This is also the way to integrate with ASP.NET forms authentication.

There are two caveats with this approach, though: These ASP.NET services provide roles and all, but they just don’t include the user name. Also, being services, I would have to call them asynchronously, which would incur at least a little time lag after starting the application, that I would have to deal with. A time lag that is unnecessary in intranet applications where the user is determined by windows authentication.

Thus my solution is as follows:

1. On the server include the information about user name and his roles in the initparams, so that it is available for the SL application right form the start, without any lag.
2. On the client pick up that information and mimic HttpContext.User to have a similar developer experience.

Of course, someone could fake this data, which might at first glance be a security flaw. But as I said, this information is only used to improve the user experience. Even if someone masqueraded as a different user, the sandbox on the client side still uses the actual user’s restrictions. And the same is true for the services that still have the responsibility to enforcing security anyway. I’m also not revealing sensitive information, since user name and permissions are not exactly protected data. And finally I could load the web page containing this data via HTTPS. Thus, form a security perspective I’m on the save side.

Server side

The server side is easy enough, since the necessary work has already been done. Step one is to include the information in the initparams within the ASP.NET page:

Step to is the respective implementation:

Client side

Mimic HttpContext.User? Well, there is no HttpContext, but we have the Application object which can be seen as a pendant of sorts. (I wouldn’t relate it to the HttpApplication, though, since an application in the ASP.NET sense spans all users.) Yet I’m reluctant to provide a base class to inject my pet feature, because that would bring me into conflict with any other library that may one day choose to do the same.

Luckily SL3 introduced the new concept of Application Extension Services (AES for short). AES have to implement a simple interface and are registered via the app.xaml. SL3 instantiates them and calls the StartService and StopService method to provide the hooks for initialization and shutdown. There will be another post about AES, thus I’ll leave it at that for now. Anyway, here’s the respective implementation:

It’s straight forward, it merely parses the information provided via the initparams. And the registration that will create the service at runtime is quite simple:

This is backed by boilerplate implementations of IPrincipal…

… and IIdentity:

From here I can use the user information at leisure, as I need it, and as I’m used to do. For example:

That’s all for now folks,
AJ.NET