The Pasithea Development Approach

Lean and Pragmatic

We'll be taking a Lean approach to developing Xprest. One of the tenants of Lean is that we won't build anything the customer doesn't explicitly ask us to build. The customer, that is the subject matter experts (SMEs), those members of the core team who are not part of IT, will tell us what they want in the way of stories. A story is a small unit of functionality that the application should exhibit, e.g., 'As a user I can submit an expense for approval' or 'As an admin I can change the current dollars per mile allowance.' A story should be accompanied by a slightly more descriptive user acceptance test. A story is a unit of work large enough to be meaningful, but small enough to be completed within a single iteration. An iteration is a period of time where developers code up the stories; typically two - four weeks. A story is given 'story points' by the development team that represents their collective estimate on how difficult a story will be to complete. The scale is arbitrary, but on the Xprest project we will be using this Fibonacci inspired scale:

1, 2, 3, 5, 8, 13, 20, 40, 100

On this scale a 1 is a trivial story, and -- though you're not supposed to assign hours-of-work to a story point -- might represent less than an hour's worth of effort. An example of a story worth 1 point is a request to change a label. An 8 on the other hand might represent a day or two worth of work. Such a story would represent the development effort for a large but still atomic chunk of functionality. For instance, the following story sounds like an 8; 'As the accounts payable system I should be able to mark an expense paid.' Note, the development effort consists of the requested functionality and all required tests.

If the development team thinks a story is more difficult than that, it can be given more story points. But any story with 13 or more points is considered an epic, and must be broken down further. For instance, if the SMEs submitted the following story, 'An expense report must route properly through the approval process,' the developers might give that 40 story points, call it an epic, and rename it the 'Workflow Epic.' The SMEs would then have to break that down into its constituent stories, each eight points or less. We have one special epic called a 'theme,' which is a story worth 100 points. For instance, we might have the 'Integration Theme.' All this said, it's up to the team to decide what works best for them; you can have 40 point themes and 8 point epics or however else you want to slice it.

At the end of an iteration, you have a 'release' where you show the customer the working application at that stage of development. This allows the customer to change or correct the direction of the project at any time to reflect new knowledge, politics, technology, whatever. The customer may tear up or reprioritize existing stories and they will certainly add new ones. And once an iteration is over, you do it all over again, until ultimately you hit a minimum level of functionality that can be deployed into the field. And once a release is out, you repeat the whole process for 2.0 and 3.0 etc.

The whole Lean approach assumes an imperfect understanding of the business domain by everyone involved in the process, and the impossibility of gathering all requirements up front. The Lean approach to development has a number of implications for app development and design:

• It does not offer a lot of time for 'big design,' favoring code over documentation
• The customer, not the development team, sets priorities
• You never build anything the customer didn't ask for
• Every story (and thus line of code) should be providing immediate business value

Note to reader: The preceding was not a complete discussion of Lean (obviously). In fact, for this project we're only pretending to do Lean. We will not have timed iterations (I'm doing this in my not copious free time), there is no core team (there's just me), there will be no scrums, no dives, no velocity measurements. The purpose of the above is to show that we (and the fictional Pasithea core team) will be taking a very pragmatic approach to building Xprest. The upshot of that is not only will we build only what's asked for when it's asked for, we will most likely end up sidestepping the murkier areas of REST and HTTP and focusing on delivering the most value for the least investment. I see this as a very good thing.

So who asked for REST?

That list of bullets leads to an interesting question: How can we spend any time on a RESTful design when the SMEs are unlikely to ever have an epic or theme that reads 'As an integrator I want to use a RESTful API?' Furthermore, the stories that sound like they might dictate some kind of programmatic network-based API (the integration stories) are not the stories that are likely to come first.

There are a number of responses to this line of reasoning. The first is that you are the technologist, and you have to select the technology that's going to work best for the team and the project. So while the SMEs never said 'REST,' they never said 'unit testing' or 'continuous integration' either. In these cases and in others you can either default on the necessary technology to implement a story or introduce new technology based on your experience or the results of a 'dive.' In fact, the technology might be such that you end up asking the SMEs to give you some points to implement it. This happens frequently with UI related things, release management, operations support, and integration.

Furthermore, while Lean is light on design, it doesn't say to never design anything. It just asks that you don't spend all of your time designing the perfect system based on (the guaranteed to be) imperfect requirements at the expense of actually delivering software. In other words, design what you need to build when you need to build it. Similarly, Lean does not mandate a single-minded focus on the stories in front of you. There will be a project roadmap which might go out a year or two (updated quarterly). You are encouraged to keep that roadmap in your head, and not do anything now that will unnecessarily hinder the ability to follow through on that roadmap.

Another reason to build RESTfully from the get go is that it has already been set in stone that Xprest is a Web-based application, and (as I hope to show) there's a very strong argument to be made that the 'right' way to build a Web application is RESTfully, even if you set aside API considerations. (This implies, and we'll return to this notion, that a Web API is just a Web site.) Building RESTfully, that is abiding by RESTful constraints, will allow us to scale the application more easily, secure it, fit it into the existing IT infrastructure, reduce the management burden, and more.

But I'm going to throw in one more reason to build RESTfully. You see, not only is Pasithea enlightened in its approach to development (it's agile, mandates testing, etc.), it's also enlightened in it's approach to enterprise architecture. Unlike the typical enterprise, where the architecture team sits in their tower spending ungodly hours and princely sums coming up with the One True Way to build and link systems together (usually completely unconcerned with and unaware of the reality on the ground), at Pasithea an architect is embedded in every core team (likely several core teams). They are as much vested in the success of the project as the development team or the subject matter experts. They participate in all communications and contribute as representatives of Pasithea's enterprise. In fact, they've actually been known to sling code -- or at least sling markup.

Moreover, the EAs at Pasithea are not obstructionist toward the development of applications valuable to the business, they are, as I said, enlightened. They recognize that speed in delivering business value is foremost. They only need to temper the development process slightly to make sure that the development teams don't build island after island of functionality and forget about the almost inevitable need to integrate systems together. The EA team does not care that project X uses Rails and project Y uses Spring (well, they do, but within reason). They don't care that project Z uses XML and project A uses JSON. They only care that the software built today could potentially be providing value two decades from now. In fact, the EA team has a phrase for this approach to architecture: 'Build for today, Architect for tomorrow.' (I lifted that phrase from my previous employer, Burton Group. Richard Monson-Haefel came up with the phrase, but the Application Platform Strategies group strung the SOA albatross around its neck and killed it.)

And having surveyed the literature, met with vendors, built a prototype or three, thought long and hard, and participated in many other development efforts, the core team has determined that the best way to build a long-lived, scalable, interoperable, enterprise-wide information system is to do it RESTfully. No more CORBA or WS-*, no more database-level integration, no more centralized ESBs or BPMs. No more islands of functionality, no more vendor controlled development or deployment environments. No more proprietary platforms that offer no escape valve. From here on in, all new development at Pasithea must be built on 'open' platforms and to some degree of RESTfulness (and REST does come in degrees). And, as part of the core team, the enterprise architect can create stories and argue his case in getting them prioritized.

Even better, the enterprise architecture group has realized that not all business value is determined and coded in one herculean effort. They believe in the idea of emerging value. They recognize the inevitible rise and importance of "shadow IT" groups. They see value in allowing business units to be self-sufficient and not having to crawl to central IT for every need. In short, they encourage teams to engineer for serendipity. Accordingly, they do not want to isolate data and functionality from anyone who has a legitimate right to see or use it. Such an approach to enterprise development allows for, say, someone in event management to know the true cost of attending a tradeshow by simply retrieving the resource http://xprest.pasithea.com/expenses/by-event/event_name (if we happen to make such a URL available).

So there you have it. We are building RESTfully from the early stages because:

• As the technologist, that is one of the enabling technologies you've chosen
• You don't want to preclude the ability to easily execute on the integration, security, and scalability stories in the roadmap.
• We're building a Web application, and the proper way to build Web applications is RESTfully
• The EA team-member is influencing stories and project design in a RESTful manner

I know that your EA team, dear reader, is not as enlightened as Pasithea's, but you don't really need that last bullet to get REST into your application. If there's a need for scalability, reliability, performance, and so on, then REST is the way to do it. If there's a mandate for the app to live on the Web, then REST is the right way to build Web apps. If there's event the faintest smell of integration, then REST is what you're looking for.