EA Consulting
James McGovern posted a question for me to answer:
“…crisply define the distinction between consulting firms who offer services that are consumed by enterprise architecture teams vs. the actual act of practicing enterprise architecture?”
In thinking about this, my first thoughts were pretty simplistic. Unless the consultant is in a long-term staff augmentation role, the consultant assists, the corporate EA does. That’s painfully obvious, however, and I don’t think it’s what James was really asking about. As I thought about this, it really came back to collaboration. In order for a consulting firm to be successful in the long term, it has to leverage the breadth of exposure it has. Within an enterprise, the opportunities for cultural breadth (corporate culture) are minimal. It may happen when a change in management is made, or when a merger or acquisition occurs, but in general, you settle into one way of doing things. A consulting firm, on the other hand, gets exposure to many corporate cultures, and has to find a way to make an organization successful within that culture, potentially being an agent for change. An 8 week or 12 week assignment is typically not long enough to introduce significant cultural change, however.
Given that the consulting firm has the breadth of exposure, it is critical that the consulting firm collaborate on engagements so that the best solutions can be offered. Even if I’m the only person assigned to a particular engagement, I will bounce ideas off of my peers to get their thoughts. By seeing what different organizations do, and understanding which approaches work best with a particular corporate culture, the engagements are much more likely to be successful.
Within an enterprise, I don’t think the notion of collaboration is as important as it should be. All too often, it’s about turf battles and clear lines of responsibility. When I ask my teammates a question, I don’t have any fear that they’re going to get recognition by my boss before I do. I ask them because I want the best solution for my client. In the enterprise world, internal advancement and recognition is on the mind of many individuals, and may come at the expense of creating a collaborative, team approach.
All of this is not specific to enterprise architecture, but I think it’s even more important at this level. In my experience as part of an EA team prior to becoming an enterprise, it became very clear that architecture couldn’t be done in a vacuum. Yet, the corporate culture makes it very difficult to foster the type of collaboration that was needed to make it successful. Too many meetings, too many fire drills, and too many time-dependent activities (i.e. top priority is some date in a project plan, not necessarily getting the best answer). This isn’t a knock on my former employer, it’s probably true of most enterprises. Enterprise architecture, by its very nature, requires collaboration. The EA focused on Security has to be working closely with the EA focused on Information and the EA focused on networking technologies, etc. Ironically, what often causes that collaboration to occur quickly? Bringing in a consultant. The consultant needs to quickly understand where an organization is, and it meets bringing all of the right people together and having the right discussions.
3 Responses to “EA Consulting”
Leave a Reply
Good response Todd. It is also worth mentioning that age-old factor that sometimes change can be proposed and realised more effectively by an outside face than a familiar inside one, for plain old human-interaction reasons. There feels like there is an interesting generalisation of this.
Of course, any kind of advisory consulting service is usually sustained by reputation and the trust held in the service provider by the consumer. Plus it has a formalised service-level (that is used as the basis of transaction), and is consumed based on the value perceived by the consumer rather than the value the provider holds in their own process and the right they feel that has to exist…
Todd – I concur with Sam’s remarks and good job also. I decided not to respond because McGovern is notorious for his dislike of, in no particular order: project managers, consultants, large industry analysts, Ruby/RoR backers, and most non-IT occupations.
My post would have wound up as a rant, and that would have been a waste of time to write and an equivalent waste of my readers time to view.
Thanks again for the well-thought-out response.
Bob
Todd,
Good response, although I am reading your blog only now, while exploring difference between SOA maturity and EA maturity. Also, I concur with Bob and Sam. I myself do not have programming background and I do not think that to be of any formidable factor in making the correct architectural assessment especially when it is an enterprise level impact. And, I have lasted in IT for about 20 years. And, thanks to OOA abstraction comes to our rescue in exploring the hidden details which could be design decisions. The issue with EA is that it deals with the higher perspective, about the planning and management necessary for the organizations to mature in an organized way keeping firm eye on ‘ROI’. And, the job of a good consultant is to define the ‘problem’ accurately for the client. Most issues lie here. Has the problem been discovered and accurately defined? Unfortunately industry being reactive gets very quickly into solution space. And, there is loss of sight on what is being solved and how it is being achieved.
There is no crisp distinction between the EA working within an organization and the EA Consultants, as they both have to define the problem first. Consultants because of their very nature of their job and their diverse exposure bring in sharpness to the learning curve and can offer decisions emotionally un-hindered. Of course! Have to hazard the termination of the services �, for having pressed the wounds during the investigational efforts. However, there is a distinction between the consultant and the contractor. Contractors are not expected to define the problem and most times are hired to provide staff augmentation. But in reality they are exploited with no recourse available to them. James question confusingly lingers with this. And, Hartford is no exception to this. EA is not a contracting opportunity as its preoccupation is in the ‘problem’ domain. It is best rendered as a consulting engagement and the success lies here.