New Compilation Book and Possible EA Book
While I have not yet embarked on writing another book, I have been published in a second book. The publisher of my book on SOA Governance, Packt Publishing, has released their first compendium title called, “Do more with SOA Integration: Best of Packt.” It features content from several of their SOA books and authors, including some from my book on SOA Governance. If you’re looking for a book that covers a more broader perspective on SOA, but has some great content on SOA Governance as a bonus, check it out.
On a related note, I’ve been toying with the idea of authoring another book, this time on Enterprise Architecture. There are certainly EA books on the market, so I’m interested in whether all of you think there are some gaps in the books available. If I did embark on this project, my goal would be similar to my goal on my SOA Governance book: keep it easily consumable, yet practical, pragmatic, and valuable. That’s part of the reason that I chose the management fable style for SOA Governance, as a story is easier to read than a reference manual. If I can find a suitable story around EA, I may choose the same approach. Please send me your thoughts either by commenting on this post, or via email or LinkedIn message. Thanks for your input.
3 Responses to “New Compilation Book and Possible EA Book”
Leave a Reply
I really enjoyed the narrative structure of your SOA Governance book and would welcome a similar treatment for EA. Much of the EA literature is quite academic in tone and I think a writing style similar to what you employed in SOA Governance would make the subject much more approachable, particularly for people who typically could care less about EA as it is normally presented.
In terms of gaps that I’d hope you address, the biggest I see relate to why companies adopt EA, how they adopt EA, how they struggle initially, and how EA is “sold” to the organization. These topics seem well suited to the SOA Governance writing style.
Best of luck with your (hopefully) new book!
If the business does not immediately see that Enterprise Architecture is a partner business discipline essential to delivering on the enterprise value proposition, it will be marginalized. It may be tolerated if it is “required” in some way through some environmental force (regulation, law, etc.). But this is not the same as a business requirement in the minds of business people–requirements that if met support the core mission (beyond just surviving).
In such a climate, if EA retreats into the budgetary protection of IT, it will be expected to carry a share of the IT “load,” at IT leadership sees it. But the stream of expectations are still coming from the business, who have already, a priori, written EA off as about technology, not things of uniquely business substance. Game over, really, for “EA” as it could be. EA becomes a euphemism. Technologists stream into the discipline, rise to the “top”–and sit there, hoping to participate in the “real world” they are supposedly paid to help.
In the actual business of powering the enterprise value proposition, business managers who are unable to effectively perform are sometimes pushed to the side (when it is too expensive to do otherwise). This is all normal business protocol; but enterprise change agents who happen to be sitting in IT are sometimes mystified.
Imagine this: a business unit takes on someone who cannot actually do the work there. I mean, the new person is a brother in law who was strongly “recommended.” Yet, the day to day work must get done. This is a real political tradeoff that won’t go away and can’t be protested. Answer–quietly put them on the margins of the real work, hopefully not resulting in a net productivity loss for the unit, while saving face, until something happens to sort it out.
It’s a purely political strategy because it’s a necessary, though potentially risky, compromise. The risk mitigation is to find a net productivity adding solution and hope for the best. The point is this: Enterprise Architects cannot be foisted on the business or they will suffer the same fate. At best they will be tolerated and the perceived risks mitigated.
IT knows this scenario well. Sometimes IT signs on to put a few “interns” on a project–or whatever. The problem is the same as for the “business”: find a net productivity gaining solution and hope for the best. Ask a team lead what they think of the idea.
If the EA “position” is institutionalized and it is perceived as a net positive only with watchful risk mitigation, it is a sitting duck for the next budget tightening, just like anything the business believes it can no longer keep around. What about all those models and all that work and the “investments” in people, processes, and technologies? Sunk cost. To business executives who must “cut their losses” in hard times, an “investment” is capital, not cost. Capital generates value; cost that does not support value is not an investment.
Check out Krafzig, Banke and Slama’s ‘Enterprise SOA Service-Oriented Architecture Best Practices’- probably your nearest competitor in the EA / SOA book market.