Architecting for the Lines!

It is so often the case that integration is a secondary concern and along with identity, audit/logging and reporting it ends way below the fadistic significance of the UX in driving developer time (and cost). Not that I want to decry the importance of UX of course – user adoption and therefore project success is often most measured on this basis, well, initially at any rate – the significance of this belies another story of why projects fail but let’s return to integration or the ‘lines’.

Many an architectural description reaches the level of a functional viewpoint and many get no further as the rapid speed of agile/iterative (explorative) development takes precedence and the architectural description fails to keep pace. However,  the functional definition often consisting of a “boxes and lines” metaphor does surprisingly retains much of its value, often providing the only overarching description of the system as a whole. But interestingly, while the “boxes” draw all the attention it is in the “lines” where the majority of the value can be found if you look. These are the primary points of integration; these define the service boundaries; the contracts by which the system communicates across its layers and tiers and across system boundaries. This is integration architecture and this is what I mean by “architecting for the lines”.

At a different level of scale I was much heartened by the following posting by Davey Winder who listed the Gartner “top 10 enterprise architecture mistakes” – most are obvious (and why shouldn’t they be) but number 8 “Architecting the ‘Boxes’ Only” was where it reawakened the dormant thoughts in my mind!

So combining other thoughts (blog posts) my first thought for the day is:

“Mind the Architectural Gaps and Architect for the lines”:)!!!

The other question I had, which is one I have when ever I read or make a list myself was “are these all really different? Am I just repeating myself with different words?”. So going through the list again I think that 2,3,6,7 and 10 are all aspects of the same thing (you could even include 1 here too and I will). Plain and simply this is about communication. That leaves 4,5,8 and 9 these two are similar in nature and relate to the actual approach or execution (you could add in 1 here but I wont) so plain and simple this is about process.

So in my overly simplistic view of the world and because I can only remember a maximum of 3 things (and only having 2 is a bonus) I’d say (and here’s my second quote of the day):

“EA projects suffer primarily due to a lack of communication and poor processes.”

For reference here’s the full list as posted on Davey’s site:

1.The Wrong Lead Architect: Gartner identified the single biggest EA problem as a chief architect who is an ineffective leader. He or she may understand EA well but has ineffective leadership skills that even a good organisational structure and staffing levels cannot overcome. Gartner recommends that such a lead architect be replaced by someone with strong ‘soft’ skills such as enthusiasm, communication and passion, as well as being well respected and strategically minded.

2.Insufficient Stakeholder Understanding and Support: This happens when employees outside the EA team don’t participate in the EA programme, EA content is not used in projects and management questions its value. Gartner’s solution is to make EA education and communication a top priority to secure executive-team sponsorship. “The key is to ‘sell’ first and architect later,” said Mr Bittler.

3.Not Engaging the Business People: When IT and business goals are not aligned, resultant problems include non-technical people trying to make technical decisions while enterprise architects become too reactionary and tactical in response to projects. To overcome this, Gartner recommends that enterprise architects get involved in the development of the business context and engage jointly with other employees in the business architecture.

4.Doing Only Technical Domain-Level Architecture: This dated EA approach is still in use in some organisations and is even narrower in scope than technical architecture. Holistic EA best-practice is much broader as it includes business, information and solutions architecture.

5.Doing Current-State EA First: Successful EA provides prescriptive guidance but current-state EA does not, so it delays delivery of EA value and hinders the creation of good future-state EA. “The temptation is often to do the easy – current-state – EA first,” said Mr Bittler. “Instead, establish the business context and then focus first on future-state EA.”

6.The EA Group Does Most of the Architecting: This is a pitfall because the EA content is typically off the mark as it was not informed by those on the business side. There is also consequently no buy-in for the EA. The primary job of architects is to lead the EA process rather than impose EA content on the organisation. They should form virtual teams to create content and seek consensus on the content.

7.Not Measuring and Not Communicating the Impact: The value of EA is often indirect, so it may not be obvious to everyone in the organisation. This then exposes the EA programme to risk of failure. Gartner recommends that enterprise architects create a slide to demonstrate each success story of EA applied to a project. They should include measurement and documentation of EA in the programme plan.

8.Architecting the ‘Boxes’ Only: Enabling better business agility and integration is key but architecting standards for the ‘boxes’ (business units) in process, information, technical and solutions models doesn’t address this. Integration and interoperability standards are high EA priorities and must account for more than just technical architecture. Architects should focus more on the links between the boxes.

9.Not Establishing Effective EA Governance Early: Enterprise architects must resist the temptation to wait for more architecture content before setting governance processes and instead develop content and governance in parallel.

10.Not Spending Enough Time on Communications: Key messages about EA are not intuitively obvious, so enterprise architects must work to educate the business. It is critical that organisations develop and execute an EA communications plan with messages tailored to each audience.