Archive for the ‘Consulting’ Category
“I wonder if Todd has observed that trust as a concept is fast declining.” I don’t know that I’d say it is declining, but I would definitely say that it is a key differentiator between well-functioning organizations and poorly functioning organizations. I think it’s natural that as an organization grows, you have to work harder to keep the trust in place. How many people in a small town say they trust their local government versus a big city, let alone the country? The same holds true for typical corporate IT. As James’ points out, trust gets eroded easily when things are over-promised and under-delivered. Specifically in the domain of enterprise architecture, we’re at particular risk because we often play the role of the salesperson, but the implementation is left to someone else. When things go bad, the customer directs their venom at the salesperson, rather than digging deep to understand root cause. We also too frequently look to point fingers rather than fix the problem. It’s unfortunate that too many organizations have a “heads must roll” approach which doesn’t allow people to make mistakes and learn. A single mistake is a learning opportunity. Making the same mistake over and over is a problem that must be dealt with.
“Maybe Todd can talk about his ideas around the importance of mentoring in a future blog entry as this is where EA collectively is weak and declining.” Personally, I think it’s a good practice to always have some amount of your enterprise architect’s time dedicated to project mentoring. Don’t assign them as a member of the project team where the project manager controls their tasks, rather, encourage them to actively work with the project team, keep up to date on what they are doing, and look for opportunities where you can help. The most important thing, however, is to have an attitude of contributing the help that is needed, rather than contributing your own wisdom. If you come in pontificating, going off on tangents, and expressing an “I know better” attitude, you’ll only get resentment. If, instead, you seek first to understand, as Stephen Covey suggests, you’ll have much better luck. While I was working as a consultant, I had a client who indicated that what they really needed was a mentor. For some consultants, this would have been perceived as the kiss of death, because it can result in an open-ended, warm body engagement, without clear expectations and deliverables. There’s a lot of risk when expectations aren’t clear and can change on a moment’s notice. In reality, the engagement was simply to listen and then offer suggestions and advice to either confirm what they already knew but lacked confidence to go after with conviction, or to suggest things that they might not have thought about. It’s not an easy task to do, but it is absolutely critical. I think an architect who is willing to stand by his or her strategy and see it through to completion, not necessarily from a hands-on perspective, but from a mentoring and guidance perspective, can build far more trust.
I was very surprised that in ZapThink’s 2008 predictions, they predicted that they will be acquired:
Our prediction for 2008 is that one of these firms will acquire ZapThink, as well as other SOA thought leadership firms, because we can establish the winning acquirer as a global SOA leader
I wasn’t so much surprised that ZapThink would eventually be acquired, but I was surprised at the public announcement. Now, I’ve never been an entrepreneur, have never been involved with a startup, and have never gone through an acquisition, but a statement like this in an open forum sent out to ZapThink’s mailing list (beyond paying ZapThink clients) would seem to indicate one of two things:
- An acquisition is already in the works.
- The company is struggling and has just raised a huge banner saying, “We’re for sale. Please come save us.”
I’d be very surprised if it was the latter case, as a public statement like this would seem to kill any negotiation position. So, I’m going to assume that the former is the case and that it won’t be long before this “prediction” is reality.
It certainly brings up an interesting topic for companies in the SOA consulting space, one area where I do have past experience. Obviously, consulting companies make money by having billable resources. If you’re a consultant and you’re not billable, the revenue is not coming in to pay your salary. The owners of the company ultimately want your salary to be paid by clients, not by them. At the same time, this makes the development of intellectual property very difficult when the consultants are 100% billable. While intellectual property is certainly an indirect source of revenue, as it can help close deals, it’s not a direct source of revenue. So what’s a consulting firm to do? It would seem that bringing in a set of experts in intellectual property development that also have experience in creating non-consulting revenue streams (training, vendor marketing) could be a very potent combination that gets around the revenue challenge. The risk here, however, is that the “vendor neutrality” that an independent ZapThink has provided becomes challenging, given that many consulting firms get deals through their vendor partnerships, and it’s difficult to be a partner to competing vendors. Even ZapThink themselves have recognized the challenges of consulting and vendor relationships in Dave Linthicum’s recent post on his InfoWorld blog. We’ll just wait and see what the future holds for ZapThink. I wish my friends Ron, Jason, and Dave all the best in 2008.
I just finished giving a webinar on the importance of SOA pilots with Alex Rosen, and I hope the attendees found it informative. One of the things that I discussed in the webinar was the scope of SOA adoption. Given the recent attention to my last post, I thought I’d discuss it a bit more, since it’s one of the two dimensions of the maturity matrix. It’s also what makes the effort more than just a “search and replace” on the SEI CMMI models as one commenter over on InfoWorld thought.
The last post introduced the levels of maturity, which are:
- Ad Hoc
- Common Goals
Those levels are a pretty straightforward way of describing the maturation process of just about anything. So what’s really import is the other dimension which defines exactly what we’re maturing.
In the case of this model, we’re discussing SOA adoption maturity. SOA adoption is not simply about purchasing technology. No one can sell you an SOA, although there was someone selling “SOA in a box” back around Christmas on eBay in Australia. SOA adoption does involve new technologies that can provide support in service development and hosting, such as orchestration engines or web service frameworks, service connectivity, such as SOA appliances or ESBs, and service management. SOA adoption also involves organizational changes. If your organization is structured around application development, which team is responsible for building a service that spans multiple groups? SOA adoption involves governance, whether it be funding models, design time policies, or run time policies. SOA adoption involves new processes designed around the consumer/provider interaction. SOA adoption involves training and communication. How do we market services that have been created to ensure their reuse? Clearly, SOA adoption involves architecture. Enterprise architecture must provide appropriate reference architectures and reviews to ensure both tactical and strategic success. SOA adoption involves Operational Management. Services can’t be dumped into production and forgotten, we must take a proactive approach to monitoring and metric collection and feed that information back into the machine for continuous improvement.
SOA is not easy. If it were, we’d all be done by now. Every company will have different drivers, and different technology needs. An assessment of their maturity in SOA adoption should examine all of dimensions required.
Interestingly, Dave calls out a common pattern that other models he’s seen define their levels around components and not degrees of maturity. He states:
While components are important, a maturity model is much more important, considering that products will change over time…
I completely agree on this. Maturity is not about what technologies you use, it’s about using them in the right way. Comparing this to our own maturity, just because you’re old enough to drive a car, doesn’t mean you’re mature. Just because you’ve purchased an ESB, built a web service, or deployed a registry doesn’t mean you’re mature.
Dave then presents his levels. I’ve cut and paste the first sentence that describes each level here.
- Level 0 SOAs are SOAs that simply send SOAP messages from system to system.
- Level 1 SOAs are SOAs that also leverage everything in Level 0 but add the notion of a messaging/queuing system.
- Level 2 SOAs are SOAs that leverage everything in Level 1, and add the element of transformation and routing.
- Level 3 SOAs are SOAs that leverage everything in Level 2, adding a common directory service.
- Level 4 SOAs are SOAs that leverage everything in Level 3, adding the notion of brokering and managing true services.
- Level 5 SOAs are SOAs that leverage everything in Level 4, adding the notion of orchestration.
While these levels may be an accurate portrayal of how many organizations leverage technology over time, I don’t see how they are an indicator of maturity, because there’s nothing that deals with the ability of the organization to leverage these things properly. Furthermore, not all organizations may proceed through these levels in the order presented by Dave. The easiest one to call out is level 5: orchestration. Many organizations that are trying to automate processes are leveraging orchestration engines. They may not have a common directory yet, they may have no need for content based routing, and they may not have a service management platform. You could certainly argue that they should have these things in place before leveraging orchestration, but the fact is, there are many paths that lead to technology adoption, and you can’t point to any particular path and say that is the only “right” way.
The first difference between my efforts on the MomentumSI model and Dave’s levels is that my view is targeted around SOA adoption. Dave’s model is a SOA Maturity Model, and there is a difference between that and a SOA Adoption Maturity Model. That being said, I think SOA adoption is the right area to be assessing maturity. To get some ideas, I first looked to other areas, such as CMMI and COBIT. If we look at just the names of the CMMI and COBIT levels, we have the following:
So how does this apply to SOA adoption? Quite well, actually. COBIT defines a level 0, and labels it as “non-existent.” When applied to SOA adoption, what we’re saying is that there is no enterprise commitment to SOA. There may be projects out there building services, but the entire effort is ad hoc. At level 1, both CMMI and COBIT label it as “Initial.” Again, applied to SOA adoption this means that the organization is in the planning stage. They are learning what SOA is and establishing goals for the enterprise. Simply put, they need to document an answer to the question “Why SOA?” At level 2, CMMI uses “Managed” and COBIT uses “Repeatable.” At this level, I’m going to side with CMMI. Once goals have been established, you need to start the journey. The focus here is on your pilot efforts. Pilots have tight controls to ensure their success. Level 3 is labeled as “Defined” by both CMMI and COBIT. When viewed from an SOA adoption effort, it means that the processes associated with SOA, whether it be the interactions required, or choosing which technologies to use where, have been documented and the effort is now underway to extend this to a broader audience. Level 4 is labeled as “Quantitatively Managed” by CMMI and “Managed” by COBIT. If you dig into the description on both of these, what you’ll find is that Level 4 is where the desired behavior is innate. You don’t need to handhold everyone to get things to come out the way you like. Standards and processes have been put in place, and people adhere to them. Level 5, as labeled by CMMI and COBIT is all about optimization. The truly mature organizations don’t set the processes, put them in place, and then go on to something else. They recognize that things change over time, and are constantly monitoring, managing, and improving. So, in summary, the maturity levels I see for SOA Adoption are:
- Ad hoc: People are doing whatever they want, no enterprise commitment.
- Common goals: Commitment has been established, goals have been set.
- Pilot: Initial efforts are underway with tight controls to ensure success.
- Extend: Broaden the efforts to the enterprise. As the effort expands beyond the tightly controlled pilots, methodology and governance become even more critical.
- Standardize: Processes are innate, the organization can now be considered a service-oriented enterprise.
- Optimize: Continued improvement of all aspects of SOA.
You’ll note that there’s no mention of technologies anyway in there. That’s because technology is just one aspect of it. Other aspects include your organization, governance, operational management, communications, training, and enterprise architecture. SOA adoption is a multi-dimensional effort, and it’s important to recognize that from the beginning. I find that the maturity model is a great way of assessing where an organization is, as well as providing a framework for measuring continued growth. That being said, your ability to assess it is only as good as your model.
Alex Rosen and I will be giving a webinar next Friday on the role of pilots in achieving SOA success. I haven’t blogged on SOA Pilots in quite some time (March 23rd of last year, to be exact). It’s always interesting to go back and read some of my past posts to see how my thinking has evolved. I had quoted the ZapThink guys, as well as Miko Matsumura in that entry, stating:
Miko stated that the only ones getting it right were ZapThink, who state that “the things you do in a pilot are the exact opposite of what you need to do to get to enterprise scale.” For the record, I agree. This all comes down to defining the pilot properly. In their book, “Service Orient or Be Doomed!” Jason and Ron call out three SOA Pilot essentials: an architectural plan (the pilot will cover some portion of it), a specific scope, and clear acceptance criteria.
There shouldn’t be much controversy over these, but yet, the case studies and whitepapers that I see presented don’t have these elements, and it’s usually because the study is equating web services usage with SOA. Taking a user-facing customer portal and extending it by allowing customers to integrate their systems directly can be a good thing, but is it really an SOA pilot?
I went on in the entry to lock in on the subject of culture change, stating: “a proper SOA pilot is to pick a problem that will require the organization to see the cultural changes that are necessary to become a service provider.” I still think that this is the case, however, I would also say that I was being just as narrow as the teams that strictly focus on using Web Services for the first time.
What you’ll find in the webinar is that SOA adoption involves many dimensions. One of those dimensions is technology based. Another dimension is cultural. I’ve been working with my colleagues on a maturity model that outlines these dimensions and the stages that an organization goes through across all of them. Pilot efforts should cover all of these. It may be done in one large program, or there may be several pilot projects. Every organization is different, therefore, there is not a one size fits all project that every organization should embrace.
If this sounds interesting to you, then I encourage you to sign up here, and listen in on Friday the 16th, at 1pm Eastern Time (Noon central, 10AM Pacific).
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.