|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
News, Blogs & Updates
« Back
Able Architecture: Part IIFrom the Field My name is Michael Montgomery and I am a practicing Chief Software Architect. Paul Preiss, founder & CEO of IASA, asked me to create an original column for IASA chronicling my experiences and perspectives of ‘slogging through the molasses’ moving a large architectural initiative forward. From the Field is the result. A cathartic labor of love. Sometimes pedantic, at others irreverent, but always insightful (in theory at least). To find other articles in the series, search on ‘From the Field’. I hope my observations inspire you to also share your comments and experiences through which we can learn from each other and ‘master the molasses’. Able Architecture: Part II Part II of Able Architecture continues to reveal my vision of Modern Software Architecture. Acknowledgements I would be remiss not to mention that I was introduced to the core ideas expressed in this article through the teaching, authorship and mentorship of Juval Lowy, Master Architect in the Microsoft Practice and general visionary. I am also a practitioner of the IDesign Method. Seek more at IDesign. Straight from the Front As I mentioned, I’m a practicing Solution Architect. I am also the lead architect on a very large SOA initiative. As one of my previous articles, What Mean You, SOA? prescribes, it is up to me to have the vision. So blood has been let. Sacrifices made. Molasses slogged and the oracles of hard fought wisdoms consulted. What remained was a powerful vision indeed. It has been 10+ years since the industry started its romance with this little acronym we call SOA. And in 2010 the verdict’s still completely out on its benefit and viability. In fact at the beginning of 2009, SOA was deemed dead in a blog shot heard around the IT world. A blog shot that was dead on to the truth of the situation, but unfortunately no one (especially the press or anyone on mahogany row) bothered to read the whole entry. Every CEO, CTO, Dev Manager and industry pundit should reread that entry and fully appreciate the truth at the end of it. I think every IT executive jumped on the byline because they didn’t want to face the reality presented between the lines: true SOA adoption is ultimately a violent evolution (revolution??). CTO’s can you say “Throw out everything you thought you knew?” and “Complete rewrite”? So now there have been volumes of books written about it. Multiple compendiums constructed in its honor. One recently published memorial is comprised of upwards of 5 books each topping out at over 800+ pages! And what is missing for every single one of them? Why a clearly defined, easy to adopt, straightforward, formal approach to SOA Design of course. Could this suspicious void be the real reason why the majority of SOA initiatives have failed historically and continue to fail today? As I declared in Part I of Able Architecture: “Without a clearly defined SOA Design Process, developers inevitably produce services that look and feel just like objects. This is a sure smell that the architecture will ultimately collapse under its own weight and eventually fail, becoming a maintenance nightmare.” What follows is a rough abstraction of what I consider to be without question the single most crucial element of any progressive Modern Development Process (wait for Part III for that vision) meant to produce Modern Software Architecture, a formal SOA Design Process. Without one you are lost. As with much of my current work, this abstraction has been informed by the IDesign Method, brainchild of SOA impresario and visionary, Juval Lowy and his team at IDesign. So no more messin’ ‘round let’s get into it directly (and I hope the MOA guys are paying attention). Vital Signs This is the list of vital aspects without which you cannot continue. The list is by no means exhaustive, but then exhaustive lists are a thing for which we are not. Exhaustive lists are, after all, exhausting, leaving you spent before you’ve even done anything. And to me they often carry the scent of the bane of our discipline, over engineering. Yes, you certainly can move forward without knowing everything. This is why we iterate on everything, including our process (more on that in Part III). While many may read this list and think, “…but of course.”, you may be surprised, as am I, that none of the contemporary approaches toward SOA Design being currently pandered satisfy even a few of these vital aspects. Don’t ask me why. I will tell you it’s my observation that they all seem to lose their way at some point and become completely convoluted. Design by exception is not where you want to be. Perhaps it’s the desire to be all to everyone. Perhaps it’s the desire to be the Grand Unified Theory of SOA. Don’t know. I do know that if you can’t sum up your SOA Design Process in 10 pages or less then you stand to a 0% chance of absorption, adoption and advocacy within a development community composed of a diverse technical acumen. Never forget that there is a fundamental point to all this; to get a job done well. As Architect, it is your role to lay out the vision for mass consumption. Trust me; you’ll need every last developer’s help to bring your vision into reality. These things are in no particular order, though I see the one that is quickly becoming my favorite, because it makes such a splash with those outside of the Dev Box (and because it is truly the Holy Grail of our discipline), is last. Modern SOA Design must: 1. Be sub-system focused 2. Be use case driven 3. Be defined by a small collection of concepts 4. Provide a simple set of governing rules 5. Provide a simple, understandable modeling nomenclature 6. Clearly convey multiple system aspects 7. Translate directly to code 8. Directly support Business Agility Something to Chew On Modern SOA Design must be sub-system focused. This aspect may be the simplest of ideas, but I‘ve come to appreciate its profound effect. As any wise engineer knows, to try to see the whole system is to go blind. It’s impossible to reason about a large complex system in its entirety. The whole must be broken down into a collection of sub-systems, each of which represents a level of granularity and autonomy that a small team can chew on. Modern management ideology recognizes that small teams of 3 to 7 members perform best. Go beyond this and negative turbulence increases exponentially, things begin to fall apart. This is also where SOA meets Agile. The sub-system delineates the Sprint. Some brave visionaries have even tried to translate the fundamentals of service-orientation into managerial techniques, literally. When you assess your problem domain, some chunks (i.e. feature sets) may announce themselves as self-evident sub-systems. Others do not reveal their fault lines until they’re placed into the crucible of design analysis. Talking through a domain’s workflows often reveals volatilities, autonomies, differentiation and new sub-systems. A sub-system focus also directly supports the Axioms of Architecture, particularly high cohesion. This is one of the many places where SOA meets DDD (Domain Driven Design). The sub-system is the context. Drive-By Use Cases Modern SOA Design must be use case driven. Ah, use cases. Still, even now they are the absolute foundation of our discipline and the linchpins of good process. They are the admittance that you have chosen the enlightened path, that you know nothing and must be filled with the details of domain. The pursuance of use cases must force you to leave the comfort of the Dev Box and inquire. If you do not, who knows what the hell you’re building. At least that’s what your end users will ask. Use cases are what all those industry pundits are talking about when they spin obtuse verbiage like, “Realized Business Value” or “Business Operation Alignment”. In my current work, we have found that by aligning requirements directly along use case boundaries, business operations fall right out and into service operations at the appropriate level of granularity. In fact, we’ve gone as far as to express use-case flow charts as simple requirement lists. Each of which becomes a service operation on an architectural concept responsible for use case orchestration. Another benefit that a use case driven approach provides, is the opportunity to validate the architecture simply by walking through the use cases and confirming that the architecture addresses each. Conceptually Speaking Modern SOA Design must be defined by a small collection of composable architectural concepts. Any astute Architect who has studied some of the contemporary SOA Design approaches knows they all fail this aspect. Without exception, concepts abound. This aspect is essential. As mentioned earlier, absorption, adoption and advocacy within your development community for your SOA Design approach directly depends on its ability to mitigate complexity. One face of complexity can be seen in architectural approaches that are teeming with concepts. There are simply too many options. While it is the job of the theorists to codify all the patterns relevant to the SOA paradigm, it is the primary responsibility of the Architect to understand and distill these options into a succinct design approach focused on the needs of their domain. As with any engineering discipline, this distillation process involves the hard work of formalizing the core values of your architecture and balancing the tradeoffs. Each domain often needs only a handful of concepts, whether you’re crafting service oriented applications, legacy interoperability facades, service buses or forwarding solutions. Believe it or not it is my experience that any given domain requires but a handful of architectural concepts to be fully expressive. Composability of these concepts is the key. Keep it Simple, Guv’nor Modern SOA Design must provide a simple set of governing rules. To a fault, this is one aspect that every approach seems to trip over itself to ignore. They just can’t help themselves. Either the rules go on and on or they are completely nonexistent. The latter actually happens more often. Contemporary approaches often spend an exorbitant amount of time defining endless SOA patterns, but say nothing of the rules that must exist for these patterns to peacefully cohabitate. SOA Design rules are all about ensuring that the Axioms and Aspirations of Architecture are preserved. The most important rules define the allowed relationships between architectural concepts. These rules are put in place to serve and protect loose coupling. Other rules define what can and cannot be placed in a given concept, which clearly define layering and encapsulation. It is my experience that this aspect also goes hand-in-hand with the previous aspect. The more architectural concepts you have, the more rules you need. The more rules you need, the more exceptions to the rules you must provide. The more exceptions you must provide the more decisions that must be made. The more decisions that must be made, paralysis ensues. Decision paralysis is an evil that can bring an entire org to its knees. It is essential to keep the rule set short, sweet and succinct. Model Glue Modern SOA Design must provide a simple, understandable modeling nomenclature, yet another vital aspect. As the industry is quickly realizing, modeling is essential to SOA Design. You simply cannot reason about the many facets of a design without a model. These are the blueprints of our endeavor. (This is architecture after all. What would it be without blueprints?) But again, your model must be easily understandable or it is worthless. This means that your modeling nomenclature must also be simple and succinct. It must also be highly consistent. Taking a tip from our big brother disciple, Building Architecture, construction blueprints keep their nomenclature simple by defining a small number of drawing elements and recasting their roles based on their context. This means something like a simple red box can have a different meaning depending on the context in which it’s used. This also means that modeling elements must be simple graphically. I mean really simple. Like box and line simple. Anything more and the graphics just detract or distract from the problem at hand. To also keep them simple, models must not over convey. They must stick to conceptual intent and not delve into functional specifics. Over granular modeling couples the model directly with logic, which is not the intent of modeling. If your modeling approach is clicking, these simple diagrams become the centerpiece of conversation. When developers spin up their design blueprints instead of their IDE, good things are happening. Multiple Personalities Modern SOA Design must clearly convey multiple system aspects. Modeling must not only express architectural composition, but also provide diagrams that convey other system aspects as well. In addition to architectural diagrams that reveal operation call chains; your architecture must also include diagrams for such things as identities and transactions. These diagrams reveal how these important system concerns lay over the architecture. Another set of diagrams must inform others on the details of binary allocation, process boundaries and logical service dependencies. By conveying these additional aspects the architecture also gives a little love to groups outside the Dev Box. Disparate groups such as Build, Test and Implementation can use architectural diagrams to make informed decisions. This helps both you and them express the architecture correctly. (And greatly reduces the length of the queue lining up at your door.) Continuous Spectrum Modern SOA Design must translate directly to code. If the many aspects of your design can’t be expressed directly in code then again your design is worthless. I suggest viewing your architecture as a continuous spectrum from design to code. When someone familiar with your design looks into the code that expresses it, they should already know what they’ll find. Binary allocation diagrams have defined the project layout and names. Concept names not only reveal their role, but directly match those in the architectural diagrams. Transactional flow should be evident based on the expressiveness of your middleware, as should identities. Since they should already know the role and purpose of each concept type in your architecture, they should know what to expect when they peer into any one of them. They’ll know where the SQL resides, as well as the business logic and where use case orchestration can be found. Additionally, since your architecture is highly self-similar all instances of a given concept type are expressed is a very similar fashion in code. I cannot stress enough how vital a self-similar architecture is to dynamic team composition. Once your developer community is familiar with your SOA Design Process and the code meant to express it, developers who are not domain experts can come and go on sub-system teams and contribute almost immediately without a lot of ramp up. The Holy Grail Modern SOA Design must directly support Business Agility. Ah, the Holy Grail of SOA. It sounds so nice, doesn’t it? Wouldn’t you love to walk into those meeting and confidently pronounce, “Yes. We can do that.”? This is where diligence, discipline and determination toward your architectural values and SOA Design Process pay off. As defined in Part I, “(business agility)… means that the same software can easily expand, contract or morph into new forms to quickly meet business needs.” Formalizing your SOA Design Process and establishing rules that directly support the Axioms and Aspirations of Architecture (see Part I), ensure opportunities for expansion. Endpoint locality can become dynamic. Both homogenous and heterogeneous scalability are supported. Internal service orientation is possible and the encapsulation of use case orchestration can mitigate the coupling needs of context specifics. All of which provide the architecture a high malleability index. These expansion joints provide both you and your clients dramatically improved business agility. They allow you to command a proactive instead of reactive stance. New features become capitalizing opportunities, instead of difficult adjustments. Your clients can reap the benefits of the same software growing with their growth with little administration cost. The artifacts of your SOA Design Process also directly support agility. Models provide pivot points for problem reasoning, identifying architectural relationships and communicating with other groups. Change management becomes very dynamic, without initially touching a line of code. Modular deployment is also supported, since change impact can be easily understood. In the end, it is the SOA Design Process that will lead and keep you on the path toward the Holy Grail. Able Architecture: Part III To conclude the Able Architecture series, Part III will outline the Modern Development Process I currently run. As you might guess, the SOA Design Process sits as the crowning jewel, central to it all.
View in Context »
Board Certification
As a Board CITA -Professional architects are fully qualified to lead large projects and corporate initiatives within the industry and their specialization. They have demonstrated their associate knowledge in practice over numerous projects and years.
Contact Colin Cairns for registration and dates. |
IASA Training Program Updates
Open Enrollment - Course Schedule We host open courses at locations and chapters all over the world. Register for any of the courses below.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
IASA Groups
 For Email Newsletters you can trust
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
