I’ve been following Tom Graves and his Tetradian blog for quite a while. His view of Enterprise Architecture (EA), namely that it is about the architecture of the enterprise and not just the enterprise’s IT systems, is one I find compelling. With some encouragement on Tom’s part, I’ve begun touching on the topic of EA, although in a limited manner. When it comes to enterprise architecture, particularly according to Tom’s definition, I consider myself more of a student than anything else. I design software systems and systems of systems, not the enterprises that make use of them.
However…
I’m finding myself drawn to the topic more and more these days. I’m finding it more and more relevant to my work. The fractal nature of social systems using software systems is a major theme of the category “Organizations as Systems” on this site. If the parts fit poorly, then the operation of the system they comprise will be impeded. A good way to ensure the parts fit poorly is to fail to understand the context in which they will inhabit. So while I may not be designing the social system which my systems fit into, an understanding of how that system functions is invaluable, as is an understanding of how my social system (IT) interacts with my client’s social system (the rest of the business) to further the aims of the enterprise.
Tom’s latest post, “Engaging stakeholders in health-care IT”, is an excellent example of how not to do things. In the post, Tom discuss attending a conference on IT in healthcare where the players had no real knowledge about healthcare. They couldn’t even identify the British Medical Journal or the Journal of the American Medical Association, much less have an idea about what issues might be found in the pages of those publications. They didn’t feel that was a problem:
Well, they didn’t quite laugh at me to my face about that, but in effect it was pretty close – a scornful dismissal, at best. In other words, about the literally life-and-death field for which they’d now proclaimed themselves to be the new standard-bearers, they were not only clueless, but consciously clueless, even intentionally clueless – and seemingly proud of it, as well. Ouch… At that point the Tarot character of ‘The Fool’ kinda came to mind – too self-absorbed to notice that he’s walking straight over a cliff
While I recently advocated embracing ignorance, it was in the context of avoiding assumption. The architect will know less about the business than a subject matter expert who will most likely know less than the end user on the pointy end of the spear. The idea is not to remain ignorant of the domain, but to avoid relying on our own understanding and seek better sources of information. It’s unreasonable to think we can design a solution that’s fit for purpose without an understanding of the architecture of the problem, and make no mistake, providing solutions that are fit for purpose is the business of IT.
Form Follows Function 
Gene:
An article in the Business Insider that was linked to this morning observed that one of the biggest assets an executive must have to be successful is the ability to listen. This is certainly true of any flavor of architect but of EAs, moreso. An EA that does not have the ability to listen and the empathy to visualize how a proposed solution might fit into the lives of the people who will live with or interact with it is not likely to be a good one.
Tom’s article on Healthcare IT was a good one. It is a domain with more actors with varying needs (and a larger price to pay for getting things wrong) than any other I can think of. Not being truly conversant with the space, I can only guess but from what I hear from friends who are in healthcare, the push for electronic records and the competition in that space have, thus far, done more harm than good. It shouldn’t be so hard but it seems to be and I don’t know if architecture, per se, is the answer. I believe, though, that a lack of empathy and an incomplete understanding of each user segments’ goals, the tasks required to fulfill the goals and the features and functions of the application systems has contributed significantly to the sub-optimal situation that currently exists.
LikeLiked by 1 person
AA: What are the well known EA models and their usefulness for representation and design.
BB: IMO the Class Diagrams of OOAD and Process Models using BPMN together are sufficient to represent all the static and dynamic aspects of an enterprise. I understand that Design Structure Matrix is excellent for both.
CC I would like to know what properties of an enterprise cannot be modeled using BB and how any of AA are better.
DD: Understanding the business requirements (problems and opportunities) and experience of how known solutions work is certainly essential but here the focus is on methods and tools (for modeling, analysis, simulation, implementation etc.) to achieve both.
LikeLike
Putcha,
EA modeling is off-topic for this particular post, but I’d suggest looking here for some answers to your questions: http://weblog.tetradian.com/tag/toolsets/.
LikeLike
OK, Thanks Gene
LikeLike
Pingback: Back to the OODA – Making Design Decisions | Form Follows Function
Pingback: The Hidden Cost of Cheap – UX and Internal Applications | Form Follows Function