Software dorks are all about patterns. I received my copy of Design Patterns: Elements of Resuable Object-Oriented Software in January 1996 when I started working at ObjectSpace [the best job I have ever had, amazing people, had a problem called "business direction of the month", hit the pooper, R.I.P.]. An early history from Kent Beck's perspective provides some insight into the early patterns movement (I Am Behind Yet Another Thought Leader Entry).
For me, especially at that time, the Design Patterns book is worth the entire price just for section 1.6 in the introduction. Back then, I committed the 24 (23? Yeah... 23) patterns to memory, and could recite them chapter and verse. I occasionally still check to see if I can even name them all from memory.
I seldom can. My memory stinks. For instance, I just tried to iterate the Creational Patterns, and I remembered Factory Method, Abstract Factory, and Prototype, but neglected to remember Builder and Singleton, even though one of my favorite refactorings is "Remove Singleton." But I have google, so all is good.
It always surprises me which ones I have forgotten, and they are often ones that I use without thinking today (e.g. the beloved Template Method). And when I go back to the book (or the table of contents on amazon), and realize which ones I forgot, my mind harkons delightfully back to geeky times of applying the pattern in this or that project, or teaching this or that pattern in ObjectSpace's OO analysis and design course, and I would realize that I am a DORK. That would trigger an ADD-like episode in which I remember feeling a sense of solidarity at the end of Revenge of the Nerds, where Louis "comes out" about being a nerd and being damn proud of it.
Or something like that.
Forward to Present: Patterns are spreading like wildfire, and they aren't limited to Christopher Alexander and the architecture or Gamma, Beck and the software monkeys. For instance, I was recently doing some research on Porter's Value Chain, and I ran across Mercer Management's profit patterns recently. The PP are a collection of business strategy patterns that cover value chains, customer, product, knowledge, channel, organization, and "mega" categories of patterns. They also drill down and expand on brand patterns, variants of their "Product to Brand" pattern.
Now.
All of that to say, enterprise architecture was conceived as a means to align what IT does with what Business does and wants to do. Now, as with most grand schemes, many every enterprise architecture efforts failed-and-how. Each time they failed, the next generation explained away why they failed in terms of problems for which said new generation now how solutions. Of course, those had better success, but ultimately, did not achieve the lofty goals laid out by the calling of enterprise architecture, as a recent BPTrends article by David Ritter on enterprise architecture discusses:
To understand how Enterprise Architecture has matured, it is helpful to look at how Enterprise Architecture has been utilized in the past. Enterprise Architecture efforts were almost always driven by the IT organization. Not surprisingly, these Enterprise Architecture efforts focused their attention on developing an inventory of IT assets, and the tools employed to capture these Enterprise Architecture models were system modeling tools that focused heavily on collecting technical system artifacts. This thorough analysis of system and technology components did allow Enterprise Architecture teams to reduce the complexity within their IT organization. Enterprise Architecture projects frequently achieved operational efficiency benefits, such as standardizing technology platforms or eliminating incongruent systems. However, the ultimate goal of business and IT alignment was seldom achieved.
Well, folks, we are on the new, false horizon. That doesn't mean we shouldn't try to crest it.
SOA, MDA, DSL, BPM -- All of these are solutions looking for problems, and none of these is the silver bullet. But they are more and better tools in our toolkit, and they make it possible to get our heads around larger problems. Of course, as another brilliant Thought Leader once wrote, "By solving problem number 1, you promote problem number 2." The next wave will come, and we'll try to deal wth it, and our hindsight will elucidate the failures of the above-mentioned TLAs, and we will woefully regret the mistakes.
For the aspiring or otherwise enterprise architect, it behooves you to gain a base understanding of how your business people think about the problems your business addresses, so that you can align your IT efforts with their needs and you can speak their language. Read the profit patterns. Read business books. Get an MBA. Find out write drives your business. Meet them more than halfway.
Comments