[Part 1 of 6. I’ve tried to keep the pieces short(ish)]
I’ve taken some of the training classes from iDesign, taught by Juval Lowy and his company iDesign. Juval refers to his method of service oriented development as the iDesign Method. I refer to it here as simply “The Method.” You can learn more about “The Method” at iDesign and here you can see Juval describe “The Method.”
This post, and the next 5, are an attempt to reconcile “The Method” and service/micro-service development with application development. As way of an example I refer to a message board / info radiator I recently built. I use this example as a way to talk about application design. More about that later.
I’ve taken “The Method” to heart. “The Method” springs from the principles of computing itself. Few of our other techniques follow any principles. OOP for example, is as dangerous as it is useful.
What iDesign does not teach is how to design and build applications in the context of “The Method.” Their classes are packed with so much valuable information there just isn’t time.
Instructors Monty and Juval are smarter than me (which is a truism). I’m sure they don’t have as much trouble with apps as I do. But everyone struggles with apps from time to time. In part this is because building apps is a team sport. In my case, thinking about “The Method” has interfered with my application design and now I know why. This is a discussion about reconciling the two.
What I’d like is better guidance on how to build the applications.
iDesign points out that “The System” should be the developer’s focus. It is death by a thousand cuts to do otherwise. Yet, most of the projects I’m likely to work on are going to be efforts to create “an app.” Organizations will need time before they understand that their money and effort need to go into “The System.” As Monty puts it, they are just beginning to understand that they need to “Escape Appland.” Until then their focus is going to be “The App.” You’re going to need to build most systems using the budget allocated for “The App.”
In this context “The System” represents the collection of services which support the business. “The System” is reusable and accessible across multiple applications. Client applications come and go. “The System” evolves.
In the PDMC (now called the Advanced Architect Master Class), Juval makes the case for how to proceed. You lay out your plan for “The System,” and show how it supports business agility. “The App” is a (tiny) box at the top of the diagram labeled, “The Client” or “Client App.” That’s not very helpful.
The AMC is jam packed with info, insight, and knowlege. There isn’t time to cover what all this means to building “The App.” But we still need to build the app.
Even the detailed design clinic spends very little time on “The Client.” It’s easy to see why. Is the client a script, an iPhone, an Android, a tablet, a 3rd party system, a WPF app, a windows (win32) app, or something else? There is too much variation in the application landscape. Those paying for your efforts will spend 100% of their time viewing your work through the lens of the apps. We cannot ignore it, but it’s not worth iDesign spending value class time on application development. They are teaching software architects how to build the service.
Before learning “The Method” I would have built system functionality into the application. Now I try to avoid it. Learning how to do this has also forced me to reexamine how I create applications. These posts are the story of my understanding of how to do this…
[part 2]
