Services, designed right, have much more runtime autonomy than components. That autonomy gives you much more ability to manage the security, reliability, and reusability of the encapsulated logic, although there can be a small cost in system performance. And service autonomy makes changes quicker and easier. That ability can save your bacon from time to time, just like it did for me one morning when I got to work....
Long Island Expressway...painless dentistry...dry wine...educational television. Inventing oxymorons like these is a wonderful party game; what others can we come up with today? How about: airline food...random order...House Ethics Committee...Service-oriented business intelligence....
That last phrase does seem like an oxymoron, at first glance. Service-Oriented Architecture (SOA) and Business Intelligence (BI) appear to be very different animals in enterprise architecture....
As I wa
We software engineers and architects sometimes feel like the rope in a tug-of-war. Pulling from one side is the short-term goal of delivering functionality, preferably yesterday. Indeed, our customers cannot justify paying for our services unless we deliver a working product, better and faster than our competitors. Pulling from the other side, however, is the long-term goal of quality. If our code becomes too disorganized or hard to understand, we cannot long remain in business, because we w
Evaluating technology options can be very murky--kind of like choosing a college or picking a spouse, only a lot more risky! If you can analyze the features you need, and score the technologies based on their ability to meet those needs, you can actually make some headway.
The .NET Entity Framework is Microsoft's new tool for object/relational mapping (ORM). While MS does have big plans for it, it does have some important limitations....
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...
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. Create a great domain model, though, and you will be able to nimbly align your software with your emerging business needs.