The typical trend in software architecture definitions of these days appear to be what I prefer to call 'COTS Architectures'. Why 'common-off-the-shelf' ? You take these architecture 'solutions' and it appears to be applicable for nearly all enterprise requirements!. These COTS Architectures appear to be used right from pre-sales proposals and typically would have the following (in a logical diagram) items :
1.) Three tiers - UI, Business, Data with usual layers:
1.1) 'UI process components', 'business objects', 'data transfer objects', 'data access layer' and of course the persistence layer with much regarded 'MVC components' spread across the tiers and layers.
2.) A couple of cross cutting concerns - logging, exception handing, aspects, error handling etc
3.) The interaction channels/protocols usually tcp/http
4.) All nicely drawn in tempting visio diagrams.
5.) You want to make it a bit more Enterprisy, add in a couple of CDN's, 'web servers', 'app servers', 'search servers', 'cache servers', 'document servers', 'enterprise service bus' et al into a cloud and there you go.
Having come across this issue across architects I have worked in past couple of years, my advice typically revolves around this line :
0.) 'COTS architecture' (if it exists) as such is not a solution, but a starting/reference point only.
1.) Where are the specifics for your application/s ? What blocks are specific to your application that I wouldnt typically find in another application architecture document?
2.) List down the 10 core requirements of your system and tell me which component/block deals with it and what is the overall strategy for the particular requirement-solution. At this point, the architect should be in a position to tell which blocks get active and which other blocks it needs. While defining a service-oriented application, it would be more about which services are consumed by a specific service and what services it provides.
2.1) Follow the KISS, SOA, SOLID principles religiously. After defining your architecture, read through these principles and figure out if it aligns.
3.) Always split the architecture definition diagrams into many - logical, technical, development and deployment at the bare minimum. Don't clutter and try to fit everything into one. If time permits, go for the conceptual, operations etc too. This additionally makes sure you need to worry about a few stuff only at any point.
Please don't get another 'COTS architecture' into your review meeting. This is not what the client/team want to see.
1 comment:
Hi Nitin - yes, agreed.
I'm not a software-architect as such, so although the principles are similar to enterprise-architecture, I'm not really qualified to comment in depth on this. What I can say is that it seems very similar to problems that we have in EA with so-called 'best practice architectures' - which in essence is whatever a big consultancy reckons it can foist on an unsuspecting client... Exactly the same as you've described above also applies in EA: the pre-packaged whatever-it-is must be customised to the context, otherwise it's more likely to be a hindrance than a help. (What the prepackaged frameworks often fail to tell us is how to do that customisation...
Another subtle danger is that using a COTS means that, by definition, you're doing the same as everyone else - which may be good in some parts of the UX, but often not elsewhere, otherwise you have no means to differentiate your software from everyone else's software, either.
In EA there are some good architectures around that are expressly designed for customisation: eTOM (now called Frameworx) is one very good example from the telecoms industry - see http://www.tmforum.org/BusinessProcessFramework/1647/home.html
Do you know the work of Simon Brown? (Coding The Architecture - http://www.codingthearchitecture.com/ ) He's a software-architect with a very good grasp of enterprise-architecture, and also of some of the themes that you've mentioned on your blog and elsewhere - may well be worth getting in touch with him, or at least exploring the videos and suchlike on his website.
Hope this helps, anyway. :-)
Post a Comment