Aggregated enterprise architecture wisdom
Christopher Bird I am pretty late to the blogosphere about the differences between social media and CRM. But in customer meetings I see this kind of confusion all the time. So here goes. Oh, and since I mainly work in the travel industry, my examples come from there.So…
I am pretty late to the blogosphere about the differences between social media and CRM. But in customer meetings I see this kind of confusion all the time. So here goes. Oh, and since I mainly work in the travel industry, my examples come from there.So…
I am pretty late to the blogosphere about the differences between social media and CRM. But in customer meetings I see this kind of confusion all the time. So here goes. Oh, and since I mainly work in the travel industry, my examples come from there.So…
I was working with some customers this week, and the topic of “how do you generate events?” comes up. Not how as in the dirty mechanics, but how when something is done manually today, getting that systematized. So, please bear with me on the following …
I was working with some customers this week, and the topic of “how do you generate events?” comes up. Not how as in the dirty mechanics, but how when something is done manually today, getting that systematized. So, please bear with me on the following …
I was working with some customers this week, and the topic of “how do you generate events?” comes up. Not how as in the dirty mechanics, but how when something is done manually today, getting that systematized. So, please bear with me on the following …
In her great song – Universal Soldier (sung here by Donovan), Buffy Sainte-Marie describes an impossible ideal for a soldier. Sometimes I think we enterprise architects have to have a similar set of impossible and conflicting attributes. We have to be …
In her great song – Universal Soldier (sung here by Donovan), Buffy Sainte-Marie describes an impossible ideal for a soldier. Sometimes I think we enterprise architects have to have a similar set of impossible and conflicting attributes. We have to be …
That’s a bit of a mouthful – but it is the synthesis of a lot of material from the SITA technology conference held near Brussels in June this year.So, I’ll put in context and then see where it leads us. The context is that in the airline industry, cost…
That’s a bit of a mouthful – but it is the synthesis of a lot of material from the SITA technology conference held near Brussels in June this year.So, I’ll put in context and then see where it leads us. The context is that in the airline industry, cost…
This isn’t just enterprise architecture. It’s about architecture at lots of levels.
Like many posts, this all started with an innocent (hah, likely!) tweet and then became richer as people joined in. Here’s the original. RT @SLSingh Bad Science by @Be…
Like many posts, this all started with an innocent (hah, likely!) tweet and then became richer as people joined in. Here’s the original. RT @SLSingh Bad Science by @BenGoldacre asks “Why don’t journalists link to primary sources?” originally posted by @frodedanielsen (someone I have never met). At which point the irrepressible Alkes Buterman and Doug Newdick chimed in.
aleksb6Aleks Buterman
But then Aleks posed the hard question… @seabird20 @dougnewdick I’m a big fan of intellectual honesty (#popper) but isn’t that easily confused for “academic” #entarch?
That’s what got me to this point – and it made me reflect on framing – using language that manages to demean an “opponent” while at the same time boosting your own value. “academic” is just one such word. Often used by teams that are under great pressure to meet a deadline and seeing that deep analysis could extend the time to delivery, demolish some closely held beliefs, make them look stupid because they forgot something. Use in context, “oh you are architects are so academic, that isn’t a concern”. While others will be thinking (“yet but it will become one…”). Of course the opposite word, used by those not wishing to do deep analysis is “pragmatic”. We have a pragmatic solution…. Thus cutting off possible debate/discussion.
Architects can (and should) find themselves in a difficult position here. They (we) must be seen to be taking the side of pragmatism, and yet ensure that the teams are not taking on excessive technical debt. We need to be asking the important questions around operability of the system, its performance and availability envelope, its need for flex when it is used in unanticpated ways. remembering of course that solutions get used in unexpected ways and in unanticipated quantities.
Make sure we use data and data values to describe the system envelope. How many users? How many transactions? How many transactions per second? What is the reliability/bandwidth of the communication path? What does it cost per transaction to use an external service? What if that service is not available? Can the system be unavailable for 1 minute, 5 minutes, 1 hour…? What does it cost to use a “pet” technology? and so on. Otherwise known as the -ilities. Sometimes called non-functional requirements, but I would argue that they are quivalent to functional requirements. If these are not met you don’t have a functional system.
In VPEC-T terms this is a classic conflict of values. The EAs are charged with the rather nebulous protection of the future. The project teams are charged with getting value out there fast. Those value systems are fundamentally at odds. So as architects we have the responsibility to be scrupulous in our questioning, demand the data that supports the project’s assertions of cost/risk/time to market. Finally those that write the checks have to decide.
What we architects must not do is put up wooly, ivory towered thinking to prove how clever we are, how stupid everyone else is, how the world will come to an end if the solutions are not developed the way we dictate. We must not be sowers of fud, but analysts of relevant data.