Software Architecture

Five Steps to Evaluate Technology Options

Chris Falter — Tue, 05 Aug 2008 17:33:13 GMT

Recently a project leadership team I was assisting had the difficult task of selecting between implementation technologies for a distributed architecture. We had brainstormed a list of candidates, and after some investigation were able to enumerate their strengths and weaknesses well enough. But then the decision-making process started to come unhinged as we thrashed about, weighing the various options. How do you narrow the field to a winner, anyway?

When I was able to frame the process in terms of the five steps you are about to read, though, the path to a confident decision became clear. While I am not suggesting that this is the evaluation methodology to end all evaluation methodologies, it certainly helped us.

Step 1: Reduce the Candidate List via Head-to-Head Comparisons. You will make your job easier if you can quickly knock out some of the contenders. Among the options we were considering for synchronizing data were

using SQL Server replication, and
writing our own application to read database records marked with an update flag, update records in a partner node with the data, and then remove the flags.

Ultimately, we realized that the application we were thinking of writing would be remarkably similar in structure and purpose to SQL Server's merge replication. Since we had no intention of re-inventing the wheel, we removed the idea of writing such an application from our candidate list.

Step 2: Build an Analysis Table. Since the goal is to learn how the technology options will influence the development of your system, the next step is to build a table that will compare the options according to how well they implement potential system features. Start by lining up the remaining technology options on the x-axis, and system features on the y-axis. The level of difficulty in implementing a feature, using a technology option, will be the data at the intersection of an option and a feature. Here is a sample of how an analysis grid might look for a distributed architecture:

Feature	Option 1	Option 2	Option 3
Workflow: Overnight Batch	Simple	Simple	Relatively Easy
Workflow: Straight-Through (Central Only)	Difficult	Very Difficult	Moderately Difficult
Workflow: Straight-Through (All Nodes)	Very Difficult	Impossible	Difficult
Data Replication: Near Real-time	Very Difficult	Moderately Difficult	Moderately Difficult
Data Replication: Every Hour	Moderately Difficult	Impossible	Relatively Easy
Post-failure Data Re-sync: overnight	Simple	Relatively Easy	Relatively Easy
Post-failure Data Re-sync: immediate	Moderately Difficult	Relatively Easy	Impossible

In this example we see that straight-through workflow processing at the central node will be difficult using option 1, very difficult using option 2, and moderately difficult using option 3. The ease of implementation (for all the feature/option pairs) ranges from simple to impossible, with four intermediate values (relatively easy, moderately difficult, difficult, and very difficult). Given the murkiness of IT crystal balls, there is probably no point in attempting a finer-grained analysis of the difficulty level.

Step 3. Assign Scores. In order to compare the various combinations of features and options, you need to assign a score to every combination. If you assign a score for a level of difficulty, you can quantify the comparison. The Cohn scale, a pseudo-Fibonacci series in which each score is about 50% greater than its predecessor, is a good choice. Many shops are already using the Cohn scale to estimate user stories in agile methodologies, so the familiarity can help. If you convert a level of difficulty into a score on the Cohn scale, you are assuming that it is about 50% more difficult than the next lower level, as you can see below:

Description	Points
Simple	1
Relatively Easy	2
Moderately Difficult	3
Difficult	5
Very Difficult	8
Impossible	10,000
Converting Descriptions Into Points (Cohn Scale)

"Impossible" is converted to an extremely high number in order to allow a numeric comparison.

After assigning the scores, the example table looks like this:

Feature	Option 1	Option 2	Option 3
Workflow: Overnight Batch	1	1	2
Workflow: Straight-Through (Central Only)	5	8	3
Workflow: Straight-Through (All Nodes)	8	10000	5
Data Replication: Near Real-time	8	3	3
Data Replication: Every Hour	3	10000	2
Post-failure Data Re-sync: overnight	1	2	2
Post-failure Data Re-sync: immediate	3	2	10000

Step 4. Discuss Features and Effort with Your Customer. Of course your customer will want to understand the choices they have. Using the analysis table from step 3, you could tell your customer that if they desperately desire straight-through workflow processing on all nodes in the distributed system, near real-time data replication, and immediate re-synchronization of data after a failure in the link between distributed nodes, the only technology available is option 1, which will "cost" 19 points. You could then point out that if it is acceptable to wait until overnight to re-synchronize data after a communications link failure, you could implement option 3 at a cost of 10 points--about half the effort.

What if my customer wants an estimate in terms of actual resources (person-days)? Your customer certainly has the right to get a ball-park estimate of the costs, of course. Since it is impractical to work up an estimate for each combination of features and options, you could perform an estimate for the lowest scoring combination instead, which will then become the basis for a conversion factor between points and effort. In the example, the lowest scoring combination is overnight batch workflow, hourly data replication, and overnight re-synchronization of nodes after a communication failure, using option 1 (5 points). If you estimate this combination as requiring 10 person-weeks of effort, then the conversion factor is 2 person-weeks per point. As a result, you can estimate that the desperately desired combination (costing 19 points) will require 38 person-weeks. Obviously, your project plan should not rely on this ball-park estimate; it is only precise enough to help the project team make an informed technology choice.

Step 5. Choose the Lowest Scoring Option for the Desired Feature Set. In most projects, the biggest cost factor (and biggest risk) is the use of human resources, so the option which requires the least effort should usually win. However, if there is a near tie between first and second place, you might want to weigh other factors such as licensing costs and vendor support in order to make your choice.

What methodology have you used for choosing between technology options? Have you used an analysis table like this? Leave a comment!

.NET Entity Framework: Is It Ready for Web Prime-Time?

Chris Falter — Tue, 27 May 2008 14:50:29 GMT

Our shop has been looking for a way to simplify the interaction between our domain layer and data layer. The data layer uses typed datasets for all its operations. When it retrieves data, it populates a dataset; when it stores data, it checks the DataRowState of all rows in the dataset, and calls the appropriate stored procedure to insert, update, or delete the data. The domain layer then uses dataset elements as the in-memory backing store for properties and collections. A collection typically uses a DataTable, for example, and a collection member would use a DataRow in the DataTable.

This arrangement has some advantages:

Between requests, domain objects can cache their state in session by caching a dataset.
DataRowState can inform the logic about which CRUD operation to perform on a DataRow. Unmodified data can also be skipped over, yielding improved efficiency.
We have considerable freedom in designing domain classes. We can make a property read-only, for example, if it corresponds to an immutable database field, such as an identity column.

This arrangement also has a big disadvantage, however. We end up with lots of properties that look like this:

public string Phone

{

    get { return dr.PHONE; }

    set { dr.PHONE = value; }

}

This property's one and only use is to map a domain attribute (an entity's phone number) to a particular field in a DataRow (dr). Our domain layer has hundreds of these pass-through properties, which are a very verbose and not especially readable way of mapping between the domain and data layers. So we've been looking for a better way to handle this mapping.

Along comes the .NET Entity Framework (EF), which provides a tool that creates a domain-to-data map in XML format. Our first reaction was: this is just what the doctor ordered! And supported by Microsoft, to boot.

On closer examination, though, the EF toolset has some growing up to do before we could consider using it in our web applications. It can generate only public get/set accessors in the entity domain model (EDM) classes, for example. You cannot make a property read-only, or internal/protected/private, or virtual. You cannot map a non-generated property to a database field. And programming in a straitjacket was not what we had in mind for a new approach.

Second, EDM classes generated by EF do not have any supported way to cache their state. A Microsoftie is working on a tool ("Perseus") that can serialize the state of an entity using an EntityBag<T> instance, but it seems somewhat incomplete (and definitely not supported) at the moment. Since our web apps do cache domain entity state, adopting the EF right now would entail an important risk.

What alternatives exist? We can license DevForce EF, which is built on top of the EF and seems to offer pretty much everything that it lacks. Or we can try NHibernate, an open-source .NET port of the Hibernate tool which is quite popular in the Java development world.

Or maybe we can just wait for the EF to mature. Microsoft has big plans for the EF, and intends to make REST-oriented web services, Reporting Services, workflows, etc. EDM-aware. So an EF investment today can yield important dividends in the future.

Even though I cannot render a definitive answer, I hope that this discussion will help readers make an informed discussion about their ORM choices in the .NET world. What do you think? Leave a comment with your insights or questions!

BOOK REVIEW: Don't Make Me Think, 2d Ed. by Steve Krug

Chris Falter — Tue, 13 May 2008 20:31:39 GMT

You've mastered web forms and controls. You've prototyped a Silverlight 2.0 application. AJAX? You're all over it. But have you really learned how to design a good web page or web site?

Steve Krug's "Common Sense Approach to Web Usability" provides surprising and sometimes counterintuitive principles that every good website must follow. Krug preaches the importance of removing clutter in order to make the purpose and functionality of a site (or page) clear--and happily, he practices what he preaches in this remarkably lucid book. Here are some of Krug's key insights:

Don't make users think! Your job is to make sure users do not have to puzzle over a site's purpose, or how to use it. Krug offers the search functionality at Amazon.com as a great example of this principle in action. A user does not have to decide what type of search she wants (by author, by title, by ISBN, etc.); instead, she can just enter whatever text interests her, and Amazon offers a list of matches, ranked by relevance.
Users don't behave the way you think they do. You've been poring over your site--reading everything ten times or more--so you tend to think that users will do the same. But they don't. Instead, the users...
- "don't read pages, they scan them." (In fact you only decided to read this review after you scanned the intro and decided it would be worth your while.)
- "don't figure out how things work, they muddle through."
Design pages for scanning. Since users are going to treat your site like a billboard going by at 70mph (rather than a textbook that they carefully work through), you should learn to design great billboards!
- Create a clear visual hierarchy. Highlight the important stuff, and indicate relationship by grouping.
- Use conventions. If your site design conforms to what users generally expect, they can more easily understand it at a glance.
- Break pages into clearly defined areas.
- Make what's clickable obvious. Use arrows or underlines to indicate that text is clickable, for example.
- Minimize noise. Prefer clarity to pizzazz.
Give users simple\mindless choices. It's okay to make a user traverse 4 or 5 links to get to his desired destination as long as each choice along the way is clear.
"Omit needless words." "Get rid of half the words on each page, then get rid of half of what's left" is Krug's Third Law of Usability. More words just make the site look more daunting, which can discourage the user in a hurry. Krug's Third Law has 2 corollaries:
- Happy talk must die. "We're so glad you're at our site! We think you'll like your experience here..." Oops, you just lost your user, who's too busy to keep reading.
- Instructions must die. Users almost never read them anyway (remember, they don't figure out, they muddle through). So keep instructions brief and simple.

Krug then discusses some details about 2 features every site must have: navigation and a home page. Krug recommends that the sections and subsections of a site be indicated with a clear set of links or tabs on the home page, and that the navigation remain available no matter where the user goes. (This answers the questions: what can I do on this site? and Where can I go from here?) Each page should have a visible name, and the site should a breadcrumb trail with arrows between the levels in order to allow a user to know where he's at in the site's hierarchy. (These answer the questions: where am I at now? and How do I get back to where I was before?).

Krug's discussion of the home page acknowledges that the forces conspiring against simplicity are enormous in any ambitious site, because there are so many organizational interests competing for the valuable home page real estate. Krug provides some useful tips for managing the problems, though, by suggesting how to use logos, taglines, and home page navigation.

Next Krug addresses the often religious arguments that site development teams often endure (pulldowns or menus? Flash animation or simple text?) with this simple advice: forget the arguments and start testing! Simple usability testing will reveal the key problems with a site, and often they have nothing to do with what the development team has been arguing about. Krug believes that frequent tests are more important than comprehensive (often expensive tests), and he offers advice on how to do testing on a tight budget (use 3 or 4 subjects; use an inexpensive screen recorder like Camtasia; try to get all the project stakeholders to observe). He concludes with an extremely useful script of an interaction between a test subject and a test guide.

Those who have already read the first edition will be pleased to know that Krug has included some very helpful new material in the second edition. Is your site accessible to sight-impaired users? If not, Krug offers a top 5 list of tips for making sites accessible, along with a pointer on how to use Cascading Style Sheets to make your site more accessible. Not to mention that CSS makes your site a lot easier to manage.... And what do you do when your boss (or the customer) wants you to do something that violates every known law of web usability? Just compose an email that borrows liberally from one of Krug's friendly "here's how it should be done" missives!

Krug sprinkles his book with examples of sites that work well (and a few that don't) to illustrate his ideas. He often offers a few "How does (or does not) this page implement the principles we've been discussing?" tests, with his own answers on the following pages. I found these examples to be enormously helpful. And Krug offers a wonderful set of additional resources for those who want to pursue the subject further, both within the text and in a notated bibliography at the end.

Because I am a long-time web user and web developer, I thought I understood just about everything I needed to know about usability to design a good site. Then I read this book, and learned a ton. If you work on web sites in any way (whether as designer, developer, or tester), the few hours you spend on Steve Krug's little gem will pay rich dividends.

Want to Write Great Business Software? Create a Great Domain Model!

Chris Falter — Tue, 25 Mar 2008 14:01:28 GMT

When you are coding in a hurry, it is very tempting to write business logic in the first place that comes to mind, such as a button click handler. However, for all but the simplest systems, such a practice leads very quickly to a chaotic system whose business logic is scattered like the ash from an erupting volcano. So let's take a step back and see how you can develop an application more intelligently.

"Divide and Conquer"

“Divide and Conquer” is a useful metaphor for organizing the effort of developing a complex system. A software architect can assign major system responsibilities to various components or layers (which I will refer to as a “part”). As long as the responsibilities of a part are understood, a developer can develop the part in such a way as to satisfy those responsibilities. And as long as the parts integrate well, a useful system can emerge.

“Divide and Conquer” has many advantages:

A team can work in a coordinated fashion on several parts of the system simultaneously, without stepping on each other’s toes.
Assigning a limited set of related responsibilities to a system part simplifies its design.
Modifying a system is easier when the part that is responsible for the functionality that must be changed can be identified.
Ultimately, the complexity of the system decreases as its various responsibilities, and the strategies for handling them, become clear. Unnecessary complexity is what can make “the last 10%” of a project go into deep cost and time overruns, as quality issues and poor design make their effects known.

“Divide and Conquer” is the driving force behind creating logical layers of a user interface, an application layer, a data layer, and a domain model in an enterprise software application.

While the advantages of separating UI, application, and data logic into their own layers are well understood and frequently practiced, the point behind creating a domain model is not as widely grasped. A domain model defines the business entities represented by a system, the activities associated with them, the relationships between them, and the rules and constraints that govern them. These are clearly very important aspects of the system, even though (from the end user’s perspective) they are not as visible as the user interface, application flow, or database. I will illustrate the importance of a domain model by examining how insurance endorsements work in the homeowners point-of-sale system that my team has developed.

Example of a Complex Business Domain

Let’s start by examining the data model for endorsements:

An endorsement can be associated with either an application (future policy) or with a risk (such as a dwelling or a vehicle). Therefore the Endorsement table has 2 foreign keys: one that relates an endorsement to an application (via the Quotenumber) and the other that relates it to a risk (via the RiskId).
Endorsements come in a bewildering variety. Some endorsements have no related data; some have one or more limits; some have one or more attributes, few of which are common between endorsements. Clearly it is unwise to attempt to create a single table with identified columns for each of the possible limits or attributes that an endorsement may possess. In addition, any attempt to create a unique table for each endorsement’s associated attributes is going to result in a very large number of tables—along with the responsibility of defining a new table each time a new endorsement type is created. Therefore, the design we chose was to create 2 dependent tables for Endorsement: an EndorsementLimit table and an EndorsementDescription table. Each table has 3 fields: an EndorsementId (foreign key back to the associated endorsement), a “type” field that allows the system to distinguish between all the related descriptions (or limits) of an endorsement, and the associated data field (a numerical limit or a varchar description). Note that segmentation and history are irrelevant to a point-of-sale system, so the schema is not designed with that capability.
Some endorsements are concerned with parties to an insurance application other than the applicant, such as an additional interest or an additional insured. Since these additional entities reside in a different table (the OtherParty table), we use a join table (EndorsementParty) to manage the association between Endorsement and OtherParty.

This portion of the database schema is represented graphically below:

So if we have a data model, why do we need a domain model? Why can’t some UI code simply write its data directly to the tables? Clearly this one way of designing a system—you can, after all, do anything with software (provided you have sufficient time and resources).

Let us consider, though, the knowledge about the business domain that the point-of-sale application must manage with regard to endorsements:

The relationship of endorsement attributes to an endorsement. A homeowners “HO 05 28” (golf cart) endorsement has several related attributes: a limit (cart value), a make, a model, a serial number, and an indicator of whether collision coverage is included. Each one of these attributes is stored in its own record in the EndorsementLimit or EndorsementDesc table. The DescType field distinguishes the four EndorsementDesc records from one another; however, the system must somehow keep track of which DescType is used for which attribute.
Differences between the format of stored data and how it is used. In a database system that does not have a built-in boolean type (such as the DB2 flavor used at my shop), there are probably as many different ways to store boolean data as there are programmers. True vs. false could be represented as “0” vs. “1”, or as “1” vs. “2”, or as “T” vs. “F”, or as “t” vs. “f”, or as “true” vs. “false”, or as “Y” vs. “N”, etc. (In one of my consulting engagements, I actually saw all of these plus a couple more in a single application.) To handle a golf cart endorsement’s indicator of collision coverage, the system must be able to reliably map between the stored data and a run-time choice of true/false.
The relationships between endorsements and other entities. Some endorsements are related to the risk being insured (such as the earthquake endorsement), and some are related to the (potential) policy itself (such as an “Additional Insured” endorsement).
The relationships between endorsement attributes. The “HO 04 65” endorsement (scheduled property) contains a set of schedules; each schedule is designated by a letter such as “A” or “J” and has a description (the personal property being insured) and a limit. Since descriptions and limits are stored in separate tables, the system must have some way of identifying and associating the schedules’ descriptions and limits.
Rules and constraints on various endorsements. The 6 schedules on a “HO 04 65” endorsement have base (default) limits, for example, such that the total limit of a schedule can be described as the base limit plus an additional limit. Mathematically speaking, we use the formula Total Limit = Base (fixed by rule) + Additional (stored in EndorsementLimit table). So the system must be able both to provide base, additional, and total limits (given the stored additional limit) and to update the stored additional limit (based on user entry).

Complexity Resolved: A Domain Model

The beauty of our team's domain model is that it completely hides all of this complexity from the user interface.

An endorsement class is defined for each type of endorsement, and it provides an interface that is radically simple for the UI developer to use. To give just one example, the golf cart endorsement provides a boolean CollisionIncluded property that can be mapped to a checkbox.
All of the other issues (which EndorsementDesc record the indicator is stored in, how the boolean is mapped to a varchar, etc.) are managed inside an endorsement class—frequently by using capabilities inherited from the EndorsementBase class or borrowed from utility classes in the domain layer.
Responsibilities are clearly grouped and assigned in this way of designing a system. Tasks and attributes that are common to all endorsements are the responsibility of the EndorsementBase class. The tasks and attributes that are unique to a particular endorsement are the responsibility of the corresponding subclass of EndorsementBase (which already has the common endorsement capabilities via its inheritance relationship with EndorsementBase). Neither of these classes needs to know anything about the application or user interface which will use them, which in turn need to know nothing at all about the internal implementation details of an endorsement class. The diagram below depicts the assignment of some endorsement responsibilities to classes in our domain layer.
The association of an endorsement with a policy or with a risk is managed via its membership in an EndorsementCollection that is accessed via the HomeApplication object or the HomeApplication.Home object (of type HomeRisk), respectively. The relationship between these various entities is depicted below.

Conclusion

There are some things that should never leak. Space shuttle O-rings. Tires. Diapers. And now that you've read this article, add your business domain model to the list. Always isolate your business domain logic in a cohesive model; do not let the logic leak into a "smart UI" or into the data layer! If you follow this rule, you will save yourself and your team much time and effort when you need to modify the business logic in your application.

Also, keep the importance of your domain model in mind when it is time to choose a development tool. A rapid application development (RAD) tool that can only design screens and logic flows might be a very good choice for building a very simple system that needs little complexity in its business logic. However, it is very difficult to envision how a RAD tool would be able to represent the relationships and constraints inherent to a complex business domain, such as homeowners insurance endorsements. Given the inherent limitations of a RAD tool, the complexity that my team's domain model currently manages quite capably would have to spill out into the flows and screens themselves.

While the result may initially seem counterintuitive, a RAD tool that at first glance makes everything look simple might very well in the end produce a system far more complex than a system produced with a set of tools that offer a robust and complete set of programming capabilities. And this unanticipated complexity can make the systems you develop far more difficult to implement on time and to extend with new customer-requested capabilities.