Todd Biske: Outside the Box

Archive for the ‘SOA’ Category

This is the afternoon keynote in the EA Summit being given by Susan Cramm, the Founder and President of Valuedance, and CIO Magazine columnist. Some takeaways from her true story of Jerry, the Irritating Architect.

• People will choose likability over competence any day.
• Motivation is built upon respect, connectivity, and pride. She used these three concepts then in the key phases of architecture: strategize, architect, lead, govern, and communicate.
• You can’t influence people you don’t know.

Overall, it was a good presentation. It definitely delivered the message of adding value to others and enabling them, rather than the opposite extreme of taking power from others and disabling them. Elements of Jerry that she described made me think of a very good book I’ve read, “The No A******e rule.”

In this panel discussion, a question I submitted was lucky enough to be directed to the panelists. It was whether or not they had a Business Architecture practice, and if so, was it part of the IT (or EA) organization or part of the business organization. Only one of the panelists, Buck Stuart of Great American Insurance, said that he had an actual Business Architecture practice, the other two, Randy Lakner of Sysco and Gouri Das of McGraw-Hill Education, both said they don’t have a practice per se, but are taking steps to ensure appropriate business input into EA practices, especially as it applies to SOA. All of the panelists agreed that the practice belongs within the business and not within IT. Randy pointed out that he had hired someone to be a Business Architect, but the effort didn’t succeed, not because it was coming out of IT, but rather because the business wasn’t ready for it. The panelists also indicated a strong relationship between Business Process Improvement initiatives and Business Architecture. Based upon those comments and my own thoughts, I would expect that increased adoption of BPM suites are likely to highlight the need and hopefully establish a business architecture practice in the organization.

Well that was fun! First off, kudos to Dr. Richard Soley from the SOA Consortium and Nick Gall from Gartner for getting us together and for doing an excellent job of moderating our panel. I really enjoyed the conversation and the answers from my fellow panelists, Bill Conroy, Global EA Executive for Bank of America, and Sam Vetto, Enterprise Architect for The Hartford Insurance Company. We covered a whole range of topics including governance, relationship between BPM and SOA, the relationship between information architecture and SOA, competency centers, funding SOA, and of course, the role of Enterprise Architecture in all of it. The topic of metrics came up frequently, just as with my previous panel. We certainly all agreed that EA has a role in all of this.

I’ve offered to address some of the questions that we didn’t get to in this blog, hopefully I’ll be able to coordinate with Gartner and make it happen. While you’ll only get my answer, one is better than none. If you attended the session, and have now found your way to my blog, please feel free to email me at todd at biske dot com or submit your questions via comments, and I’ll be happy to offer my thoughts. Also, I believe that this session will be available as a podcast in the future, so keep an eye out for it. I’ll be sure to link to it from here.

The EA Summit has begun and Nick Gall is giving the opening keynote. He’s discussing a “middle-out” architecture style that “enables decentralized change through … minimal constraints.” He’s working hard to not digress into a REST discussion. 🙂 The visual metaphor is an hourglass, where there’s a small set of constraints in the middle that enables things to work, and things that grow outward in both directions. In the upward direction, it’s about the business. Many businesses can all be made to fit within these small constraints. Going down it is about the technology. Once again, there’s a multitude of technologies that can be made to fit those constraints. Many web servers all support the core web protocols.

Beyond the natural ties back to a REST approach, there’s a lot of truth to this metaphor. Both the business and the technology can be viewed as a hierarchical set of constraints. There are a small set of high level constraints that control everything that goes on underneath them. Architecture begins with these, and they are broadly applicable. Put too many of these things in the middle and, as Nick puts it, your waistline grows. If your waistline grows, things get more bloated, and you need more and management, process, etc. to ensure the adoption of these constraints and all of the exceptions associated with them. Doing income taxes comes to mind, for me. How many of the questions on my tax form are applicable to me? Having to go through the process of them makes things more complicated. Many things on the tax forms are so complicated that it’s difficult for an individual to know whether they even apply or not. At the opposite extreme, the narrowest of waistlines would be a standard flat tax. No exceptions, no complexity, just take 17% (or some other appropriate number) and give it to the government. Is there a need to distribute that tax to the local, regional, and federal agencies? Yes, but does that complexity need to be exposed to everyone in the middle? No, it doesn’t. Move it up/down in the hourglass to the areas that care about it, but don’t expose it generally to everyone.

If nothing else, Nick has certainly managed to get me noodling on this whole “narrow waistline” and hourglass approach. It’s a very interesting concept. The immediate concern that I have is that there’s a lot of changes that go on within the sands of the hourglass, and there’s a tendency for things to push toward the middle. To make this work, I think we’ll need appropriate guidance on how to maintain our perfect hourglass shape over time. I suggest using analogies of eating healthy and exercising frequently.

I’m sitting in a case study session on SOA Governance. Barney Sene, VP and CTO of Ingram Micro, is currently speaking and just had an interesting slide up. Because they are a global company, one of the things they always do is examine any proposed service (documented through a Service Requirements Specification – SRS) for specialization that may be required for global requirements, versus the context in which that SRS may have been created. I now work for a global organization, and now clearly understand the need for this. I have firsthand knowledge of a business service that will have differences in how it must operate based about the geographic regions involved. Barney’s slide demonstrated how the SRS provided a significant percentage of the final definition, but these other factors like globalization chipped away at the remaining 20%.

From a governance perspective, what I liked about this was that it presented an approach that didn’t mandate, but rather encouraged appropriate behavior. If the company has stated “We are a global organization” rather than acting as a collection of regional organizations, then every project should be asking the question, “Are there any regional nuances that must be factored into the architecture and design of what I’m producing?” This example also got me thinking about what other factors should be explicitly encouraged in this same way, simply because people aren’t used to thinking that way. Globalization makes perfect sense. Security also makes sense. We have to realize that many designers and developers are primarily concerned about the functionality at hand, and need some encouragement to think about factors “outside of the box” that may influence both the non-functional areas as well as the functional areas. Because this is a shift in thinking, it must be encouraged first, enforced second. Dangle the carrot, and only use the carrot when necessary. What other items belong on the list that can take a service from an 80% solution to a 100% solution?

I attended a session from Michael Blechar titled “The Yin & Yang of Processes and Data: Which Will Be King of the Next Generation Applications?” A big title, and as a result, Michael covered a lot of topics. While there wasn’t any new information for me, I would say that this was one of the better big picture overview presented at the conference. Some of the topics he hit on:

• The challenge of multiple metadata systems, and how some of the vendors are approaching it, in particular IBM. He specifically touched on CMDBs (Configuration Management Database), Service Registry/Repository, Software Development Assets, Database Metadata Management, and more. IBM’s approach is to provide a collection of metadata services that reside above all of this systems, providing a federation layer. Hmmm…. this sounds vaguely familiar, I think I called it Master Metadata Management and spoke more on it here.
• The challenges in determining when to use them versus pushing the logic up into a service layer. It discussed the importance of service ownership.
• The importance of information modeling and its importance in SOA.
• The importance of service ownership/stewardship.
• The importance of enterprise architecture operating as a team, and not having silos of business architecture, technology architecture, and information architecture that don’t talk to each other.

Overall, this was probably a good session for many people and hopefully helped them see a bit more of forest for the trees.

The Power Breakfast is over and done. If you saw me there, hopefully you got something out of the conversation, although it was unfortunate that the session wound up being four independent case studies without a lot of time for audience questions, rather than a discussion among the panelists and the audience. Despite this fact, there were some good points that came out, and I wanted to highlight the ones that struck home with me here:

• First, as the preliminary results of the SOA Consortium funding survey have indicated, there’s no uniform initial approach to SOA. Some leverage an SOA program, some expect service development out of existing projects, etc. One of the panelists, Leo Schuster from National Bank, indicated that they had an SOA Program. In my experience, I’ve never encountered a funded program whose sole goal was to produce SOA. I’ve always worked with business projects/programs that wanted to leverage services as part of their efforts. Personally, I prefer the latter, because as Victor Harrison from CSC pointed out, programs end. Will your SOA efforts ever stop? They shouldn’t. So, while you may have solved the initial funding problem, you haven’t solved the ongoing funding problem.
• Second, metrics are critical. Every single one of us mentioned metrics. Without them, how can we say that we’ve accomplished anything? The oft-mentioned notion of agility is frequently associated with the time to deliver a particular solution. To show that we’re more agile, we need metrics of how things have been and how things are in the future. Beyond efficiency metrics, there’s also metrics associated with service consumption: number of consumers, usage by consumers, min/avg/max response time, etc. In my own experience, merely making these metrics available, and now at a finer level of granularity than the entry points into a web application were very beneficial. This visibility didn’t exist before, so anything was better than nothing. If you’re already collecting this, now you can start to do baseline comparisons to show improvement.
• Third, service ownership is key. It was great to hear someone else say that the project-based culture of IT can be in impediment to SOA success. While your SOA shouldn’t have a lifecycle, individual services do have a lifecycle. If you simply have someone who is responsible for service lifecycle management, you’ve got the key piece of the puzzle for many of the discussions around service granularity, funding, etc. If you don’t have a service owner independent of the consumers, then each consumer is going to try to push things in the direction that has the most benefit for their project, but yet no one will own the service. This in-fighting can be very detrimental to SOA.
• Finally, lets get Service Portfolio Management (SPM) right from the get-go. There are many sessions here at the summit concerned about application portfolio management. We’re all behind the eight-ball here as all of these applications have been built/bought over 5, 10, 15, 25, … years without anyone managing them as a whole. The last thing we want to do is repeat the process all over again with services. We’re at the early stages of SOA and can now do it right. Anyone saying that they don’t need a registry/repository yet because they haven’t reached “critical mass” is potentially making a big mistake. They only need to look at their struggles in trying to do application portfolio management as an example of the path they are heading down.

To those who got up early for breakfast and attended, I hope you found some nuggets in the presentation that were valuable from me or from the other speakers. I’d be happy to have followup conversations with anyone who felt like their questions are still unanswered, or those who want more depth on some of the things they heard.

I attended a session on assessing maturity in IT given by Susan Landry. She outlined their maturity model which covers eight different dimensions. The maturity model has familiar levels if you’ve looked at my work, CMMI, or COBIT. Level 1 is ad hoc, level 2 is repeatable, level 3 is defined, level 4 is quantitatively managed, and level 5 is optimizing. The eight assessment areas are:

1. Application Portfolio Management (APM)
2. Project Portfolio Management (PPM)
3. Staffing, Skills, and Sourcing
4. Financial Analysis and Budgets
5. Vendor Management
6. Management of Architecture
7. Software Process
8. Operations and Support

The most interesting part of the discussion, however, was a single slide that discussed the interdependencies between these areas. For each pair of areas, the relationship was classified as either highly interdependent or moderately interdependent. Having done a multi-dimensional maturity model before, a big challenge is in determining whether or not it makes sense to get scored high in one dimension or low in another. In my SOA maturity model, I typically found that when scores were two or more levels apart, it was probably going to cause some imbalance in the organization. If the scores were even or a single level apart, it was probably workable. What I didn’t do, however, was to explore those inter-relationships and see if that theory uniformly applied. While Gartner didn’t provide a lot of depth in the inter-relationships, they did at least make a statement regarding it which can provide a lot of assistance in determining how to interpret the scoring and what actions to take.

In this session, Frank Kenney and Val Sribar, are discussing agility and application development in the context of a fictitious fable of a web unit in a business organization that is operating in an agile manner and how it works with the traditional application development organization. While I find the fable a bit far fetched, since I’ve yet to see a business unit pushing agile processes on IT, it’s usually the opposite, there is one key point that they made. They called out that not all business units may be ready for an agile approach, simply because they don’t change that rapidly. Hopefully, this will be a common theme throughout the conference. Any approach that claims to be one size fits all is probably going to run into problems. Whether it is agile, REST, Web Services, SOA, EDA, etc., there are always scenarios where it works well, and scenarios where it doesn’t work so well. A key to success is knowing not only how to apply a particular technique, but knowing when to apply it.

Further in on the presentation, they went through some different areas and discussed how they contribute to agility. In the subject of business process actions, they called out that there should be a single business person clearly in charge of a particular process. I think this applies not only for processes, but for services as well. There needs to be a service manager for each service in the organization. An individual may manage multiple services, but without a service manager, there will be problems.

On the subject of reuse, Frank Kenney pointed out that incentives, metrics, testing, methodology, and inventory management (registry/repository) is necessary to make it a reality. I think this is a good list, although I would have liked to see marketing included. While a registry/repository and methodology do focus on the consumption side, if a service or reusable asset is placed out there in a way that makes it difficult to find, the burden is on the provider to improve it, which involves marketing.

Near the end of the presentation, Val and Frank presented an “Application Group of the Future.” Val called out breaking out groups for User Experience, Business Processes, Business Information, an Integration Competency Center, Business Relationships, Software Quality, and Information Infrastructure. These groups would all be operating in an agile manner. In addition, the traditional development groups would also exist. These groups would all leverage common environments to support their efforts. There was one thing about this picture that I disagreed with, which was the placement of SOA. They sprinkled the entire organization with SOA experience, which makes sense, but they didn’t call out the separation between organizations focused on service consumption and organizations focused on service production. If anything, service production (unless it happened to be an automated business process) was buried in the tradition development group, and I don’t think that will cut it. On the bright side, one of the things that they called out which was very interesting, was the need for dynamic budgeting. Val made a comment that the web and mobile applications are challenging the way we book business early in the presentation. This need for dynamic budgeting is an analogous example to how a new agile IT, challenges the way we traditionally do budgeting. Annual budgets won’t cut it, we’ll need to make it more dynamic and responsive in real-time.

I’m in the keynote for the Gartner Application Architecture, Development, and Integration Summit. So far, the biggest thing that the panelists have mentioned is this overlay on the traditional Gartner hype cycle which defines things as in the “Zone of Competitive Leadership (ZCL),” the “Zone of the Mainstream (ZM),” and the “Zone of the Decline (ZD).” If not apparent, things that are in the ZCL are higher risk but higher reward. Things that are in the ZM are necessary for companies to adopt to simply keep up with their competitors. Things that are in ZD are for the most risk averse. Yefim Natis put Client-Server architectures in the Zone of Decline, as an example.Yefim also called out that this coming year, “Interactive” SOA (which is Gartner’s “traditional” SOA) will move into the Zone of the Mainstream. I’ll have to go back and look up what their definition of interactive SOA is, but unless it’s just the standard integration-based approach to building the same old solutions, I’d be hesitant to say that SOA is mainstream. Using services where we were previously using EJBs or other distributed components clearly is mainstream at this point, but until we see more projects that are strictly about building services and a separation between the construction of consumers and the construction of services, I think we’re still in the ZCL.Yefim also talked about other types of SOA, including Event-Driven SOA, WOA, and Context-based SOA, which he’ll cover in a later session. There was then some brief discussion about the SOA platform, and now we’ve moved onto a discussion from Gene Phifer about Web 2.0, Cloud Computing, Computing as a Service, Social Networking, etc. It’s nice to hear them giving a decent amount of attention to this. Nothing new in the quick overview, but keynote-level attention is a good thing.Finally, Matthew Hotle is wrapping up with a discussion about governance. They’re emphasizing a very lightweight approach, with just enough decision support to ensure that the organization can still be agile. There’s a session on their Maturity Assessment for Application Development later in the day that I plan on attending. From what they showed in the keynote, it’s a five level maturity approach that sounds very similar to what I’ve discussed in the past (here, here).More to come from the conference, I hope to be blogging throughout.

Just a reminder, I’ll be part of two panel discussions in Las Vegas next week, the first at the Gartner Application Architecture, Development, and Integration Summit on Tuesday morning, the second at the Gartner Enterprise Architecture Summit on Wednesday afternoon. If you’re attending and want to chat or simply introduce yourself, stop by or drop me a line at todd at biske dot com.

In his links post, James McGovern had some comments on my Long Tail of Applications post. He stated:

Todd Biske wants to eliminate the term “application” as it implies a monolith. I would like to point out to Todd that there is another usage of the word that still remains important which primarily indicates a funding model. It is possible and viable to build a great SOA while still letting the finance folks think in terms of applications. Removing the term from architects is a great thing but very disruptive for other parts of the enterprise.

I’m glad James brought up the whole funding model aspect of it. As he rightly calls out, the removal of the term “application” is probably not terribly disruptive for architects, it’s very disruptive for the rest of the organization. How many IT departments have organizations with application development in the title? How many project charters contain the words “…deliver an application…” in their text? If you agree with the premise that, in general, IT is not delivering at the level it could be, then something needs to change. We need a disruption. If that disruption ripples all the way up to the way projects are defined and funded, then so be it. This type of change doesn’t happen overnight, and is not going to be without many bumps in the road.

Does everyone need this type of disruption? Perhaps not, but I think that it’s a very difficult thing to determine. If you’ve read The Innovator’s Dilemma or The Innovator’s Solution, you know what I’m talking about. While I can envision what an organization that has truly embraced SOA and BPM technologies might look like, it’s far more challenging to determine what the path to that state is, which can also leave you wondering whether it’s even necessary. Ultimately, it only becomes necessary when some unknown competitor embraces it and starts beating the pants off of you. Finding that first example that justifies trying a new way of doing things is hard enough, finding the second and the third to justifying sustaining it is even tougher. I’m up for the challenge, though!

I had a great conversation with a colleague (thanks Andy) recently regarding BPM technology and the software development lifecycle. We were lamenting the fact that whenever a new development paradigm comes along, we run the risk of taking one (or more likely many) steps backward in our SDLC technologies.

Take, for example, test driven development (TDD). (Aside: I enjoyed the latest ARCast on TDD from Ron Jacobs.) How do you unit test when doing model driven development as is the case in most BPM tools? What are the appropriate “units” to test? For that matter, how does a continuous integration model work? Can the models be stored in a source code management system like Java or C# code? Can I run automated builds? Does the concept of a “build” even apply anymore? I have a hard time believing that the use of these new model-driven tools somehow negates the need for testing and continuous integration. It would be great to hear more on how the best practices we’ve learned in writing large systems in Java and C# now apply when programming through pictures from some of the vendors in the space. I don’t know whether any of the vendors have given any thought to this, but I have seen organizations that have run into some of these questions as they adopted BPM technologies. Anyone have some answers?

Update: InfoQ posted some similar thoughts under the heading, “Why do Java developers hate BPM?”

I received a press release from The Open Group a couple of weeks ago regarding their IT Architecture Certification (ITAC) program. This is a subject that I haven’t discussed on my blog until now.

Personally, I’ve never been a huge fan of certifications. Back when I was assisting in the interviewing process for Java developers, I saw quite a few developers who were best described as “book smart.” That is, they had memorized sufficients amounts of the certification guides from Sun, but taken outside of that certification context, their ability to contribute value was questionable. It seemed to me that these certifications were really only of value to consulting/contracting firms, because it gave them some kind of a stamp to indicate that the people they were providing had some level of qualification. Of course, the organizations doing the certification gained value as well, as people paid for the training/testing/etc.

When people discuss a need for certification, it ultimately comes back to a need to make the process of finding suitable candidates easier. In my experience in corporate IT, there’s always been at least one group that does pre-screening of candidates before they ever show up on the desk of the team performing the interviews. It’s likely that this includes HR, and also likely that it includes a number of contracting/placement firms. After all, the value proposition of these placement firms is that they provide “qualified” candidates, versus just opening the flood gates to resumes from the Internet. The real problem in all of this is that certifications are disconnected from how people work on a day-to-day basis.

Take the P.E. (Professional Engineer) designation as an example. In the context of a civil engineer, there are certain things that only a P.E. is allowed to do regarding designs, otherwise the company producing that design puts themselves at significant legal risk should that design fail. No respectable civil engineering firm is going to have designs that haven’t been signed off by a P.E. The same thing does not exist in the world of IT. Not only is there no standardized “sign-off” process, but there also isn’t any kind of liability (other than potentially losing your job) if you deliver an IT solution that fails.

If there is no standardization in the way that we perform the work, how can any of the potential value in certifications be realized? Where I see organizations and individuals struggle is where there’s a mismatch between the culture of the organization and the desired culture of the individual. I’ve seen people that are viewed as industry experts struggle mightily because the way that they like to operate simply doesn’t match with the way that the company operates. I’ve also seen teams that may not have had the strongest technical people be far more successful because they simply work better as a team.

At the architect level, my experience has shown that the successful architects tend to be the ones that excel at leadership, influence, and communication. They have to be strong technically, but technical knowledge alone does not make a successful architect. From a technical perspective, it’s probably even more critical that the architect can learn quickly and focus in on the critical aspects of the solution, rather than simply having significant technical depth and experience. How do we assess this? While technical knowledge can be tested, the interpersonal skills are very subjective. On top of that, not only may two people judge interpersonal skills differently, the aspects of what an organization finds important in interpersonal skills will vary. This factor makes it very difficult to come up with a certification process that will really add the value that the proponents claim is possible.

I won’t go so far as to say that certifications have no value, but in terms of IT solution development, they’re simply another tool. A blanket rule that sifts out any resume that doesn’t include certification Foo is probably going to result in you missing out on many good candidates. Because of the lack of standardization in job descriptions and processes, certifications are simply another data point to be factored into the equation. James McGovern has commented on how he likes when potential candidates have blogs. The lack of a blog shouldn’t rule out a good candidate any more than the lack of a certification does. The existence of a blog, certifications, speaking experience, etc. all must be examined.

Nortel and IBM recently announced joint technology for integrating business applicaitons with communication services (InfoWorld article, SearchSOA article). Personally, I’m glad to see this announcement. I first had conversations around communications services with a colleague back in early 2006. He was looking at the future state communications infrastructure and came to me wanting to know how to make sure it would fit in with SOA. I had never thought about this before, but it made perfect sense. Communications, clearly, is a capability, so why shouldn’t those technical capabilities be exposed as services? Kudos to Nortel for having a press release about this and really emphasizing how this can play in a company’s SOA is a win in my book. While I’m sure other vendors in the communications space also have these capabilities, they’re not emphasized. As a result, it creates an atmosphere for more silo-based thinking around point-to-point integrations, rather on how this capability fits into the broader collection of enterprise capabilities.

The field of communications would also probably make a great case study or research project. If someone were to try to define communications services 10 years ago versus today, you’d have a very different collection. Would a presence service even be mentioned? Would it have been voice only, or would it have involved text/instant messaging, email, and/or video as well? It certainly makes the case for active service lifecycle management versus defining the services once and then moving on to the next project. As you define your service domains, you have to recognize that the definitions of those domains and even the collection of domains themselves will change.