Ever found yourself describing a design that you think is so 'obvious' that everyone must already understand it, only to find that almost no one understands it... and then find that there is a product that uses it?
That has happened to me more than once. It is frustrating.
So, I'm at the local meeting of the IASA listening to a presentation on 'grid' computing, which is a distributed computing architecture that ranges from SETI-style multi-processing to wide ranging smart-cache technologies. Interesting stuff.
Then it occurs to me that the simple model I've been describing for event driven cache management, for well over two years, is really a simple form of the same data replication that is enabled by these tools. I didn't think of it originally... I had heard an ESB vendor describe this design many years ago, but he didn't give it a name. The design stuck in my head but I didn't have any good category for it.
Well, at least I now know what to call it. Gigaspaces calls this the 'Data Grid.' Other vendors have products that compete, from what I'm told. I'll have to dig.
Liking it. Now, I need to find it on the MS stack...
a few days ago, I blogged about "what is the right level of detail to describe an interface," and one good soul asked me to include unit tests.
OK. I like Test Driven Development. I really do. I think it is an excellent practice that forces you to think in "specification completeness" terms, which is not something that comes naturally... it is learned.
But honestly, if I am communicating with a person who has not learned to think this way, then a unit test is code. It is not a spec. And if I am communicating with a person who is a program manager, and not a developer, then a unit test is code, not a spec. And if I am communicating with a person who loves unit tests, but only in their favorite tool, then a unit test may cause "more heat than light." None of these three people will gain much from a unit test.
When I am communicating, I don't always know who I am communicating with (like right now). So unit tests, while valuable and useful for the person who is writing the code, and valuable and useful for the people who need to validate the code and maintain the code and even understand the code, are not always the best way to communicate about the code to an unknown but hightly technical audience.
Pictures. Diagrams. The friggin' UML, for goodness sake. (High fidelity diagrams). I can, in four diagrams, illustrate more about an interface's dynamic behavior than I can in a long list of unit tests.
Let's use TDD. Let's promote TDD. But let's know it's limitations.
I personally believe that Event Driven Architecture (EDA) is the future. I don't believe that SOA can deliver many of the promises attributed to it without a heavy dose of EDA. Of course, to make this work, we need standards.
And that is where the Object Management Group's SOA SIG comes in. OMG has put out a Request for Information (RFI) on Event Driven Architecture to get feedback from the general community. If you are passionate about SOA, I strongly suggest you start with Brenda Michelson's excellent blog post on this RFI and go from there.
Time is short. If you wish to contribute, start today.
I spend way too much time in meetings. I've been working myself ragged trying to keep up with my deliverables, and not able to get any of them done, mostly because I spend my days racing from one meeting to the next, often in different buildings, sometimes in different campuses. (Microsoft has more than one in the Redmond area, with over 120 buildings).
This week, I came down with something. A cold, I think, but my primary symptom was severe exhaustion. I spent the first day at home mostly sleeping, but the next day at home catching up on my architectural deliverables, even though I was missing about five 'important' meetings.
And that's when it really hit home... the meetings just were not that important. It is OK to skip a few, or turn some down, if it means I can leave myself time to actually do the work they pay me to do.
I asked and some of the other architects have a standing set of "meetings" for three hours a day, three days a week, that they set aside to get work done... time when they cannot be easily 'scheduled' by someone who believes, perhaps with all the best intent, that they need an architect in the room.
But, to be honest, sometimes it is better for me, and the room, if I skip meeting #5 on the process for figuring out how to handle the return of a volume license from a company that didn't buy one. (I made that up, but it sounds like the kind of timekiller I'm talking about).
Saying 'yes' to another meeting request means saying 'no' to my son who wants to ride a bicycle with me in the early evening, before the sun sets. That's the perspective I need to keep.
As a company grows, new situations arise, and a great deal of effort will emerge to cope with the "new new problem." After a while, it is not a problem anymore. However, as the company continues to grow, that 'problem' becomes an opportunity.
Example: let's say you are in a small firm that makes pens. You are competing with major players like Bic, so you have a niche market. You make pens that are delivered to companies that personalize them for corporate marketing programs and conventions.
Along comes a 'problem.' A salesman figures out that you can make a custom pen designed for cars that come pre-installed in the manufacturing process. It is a problem because now the pen itself has to be customized, not just the writing. You develop a process to handle this one-off situation and make some money. Your sales team takes advantage, and with the blessing of the CEO, goes after every car company in the world to make custom pens to fit in cars.
And, thus, a market is often borne by the 'sales door.'
Of course, someone usually forgets to tell IT until after the first 50 orders are already in the door. Turns out the fulfillment system has a problem. It invoices the wrong people. You need to add some data elements and rework the business rules a little. An IT team launches a project, and you design the fixes. Maybe you use an agile process.
Then the sales team starts adding features. You see, they've been hankering for a CRM tool for about a year, and have been frustrated with the slow pace of the CRM project, which you are not working on. You are working on the fulfillment system.
But they come to you and say "please add these features" and you spot, right off, that the capabilities they are asking for are not fulfillment. They want the ability to track sales contacts against the customers. The sales team is asking for CRM features "through the back door."
What do you do?
If you add a few features, just to make them happy, you may slow down the CRM project substantially, because they now have to integrate with your data... data that is in the wrong place. If you don't, you can make your customer angry, and they are rising stars. The CEO loves them right now.
This is where Enterprise Architecture is paid to step in and stop the insanity. EA can review projects, find suggestions for overlapping functionality, and redirect the efforts.
But for it to work, the dev team has to respect EA enough to call a halt to those features. They have to back off on those, even though the EA member is not actually a part of the paid project team.
And that is where you need clear leadership. Clear committment to quality and excellent operations. EA needs to be able to talk to the right people and have the right decisions made, and respected.
A decision to do the right thing may be a difficult decision. If handled well, it won't hurt. But if leadership is lacking, or committment to architecture is lacking, then Enterprise Architecture will be labeled as a noisemaker and either the customer or the dev team, or both, will write EA off as a waste of time and effort.
Don't let that happen.
When you join a team, find the lines of leadership and establish your role. Explain that you may be called upon to change the scope of overlapping projects, and that you will need their support. Prepare the leaders. The day will come when you will need them.
We have a pretty good solution for portal code interface in our team. We've been using a home-grown portal for about a half-dozen years and it has grown to be fairly sophisticated. We have role-based-security, page auth, object auth, data item auth, row level auth, and user attributes. It's pretty sophisticated.
Now, we have to describe it to another team that wants to understand it. Problem is... it's homegrown and most folks just use the modules that someone else wrote to do most of the basic things. So it is not that easy to find a concise and descriptive document already in existence.
So we write one... right?
OK... what do we put in it? I'm serious.
If you have a code interface, and you need to describe it from a simple API standpoint, it may be simple enough to extract the documentation using .Net, but if you want to actually 'describe' it to a dev team so that they can consider the features of your interface, and perhaps put a few into their product, you need a much richer description than MSDN.
Interaction diagram. Class diagram. Some text describing the use cases. Notes on data structures, dependencies, and type inheritance.
That's about 6 pages of description for a simple interface... 50 for a complex one. Is that the right level of detail? If you were a developer, and someone else had created an interface and you want to evaluate your tool, figure out how hard it may be to add the features from that interface into your library... how much detail would you want to see?