Service Oriented Architecture - SOA

A couple of weeks ago, I asked a simple question on Twitter: Should Enterprise Architects have/get an MBA? That meme made its way to InfoQ, so I figured I should actually post my own thoughts on the subject.

First, a full disclaimer: I don’t have an MBA. I do have a MS in Computer Science from the University of Illinois (go Illini!). At the time I got my Master’s, a friend of mine took a different route and did a combined MCS (Master of Computer Science)/MBA degree. In retrospect, I wish I had taken that route. Part of my reasoning to not go that route was the whole MCS designation. Who has ever heard of that? Even from an institution like Illinois, would anyone have known what it is? For those of you wondering, it’s basically a course-only option for a Master’s degree. Getting an MS required writing a thesis. Getting an MCS did not. More importantly, however, I realize now that my interests lie more in the application of technology than in the technology itself. I had inklings of it back then, but at that time, it was far more important to be strong in technology first, rather than the domains in which it was applied.

Today, it’s a different story. There are no shortage of tech-savvy people in the business, so simply being a technology expert is not going to get you as far as it did 20 years ago. I’ve seen enough headlines that say IT departments are shrinking, meaning that some of the technology knowledge needed is being provided by people outside of IT. I don’t think this trend is going to reverse itself, so those of us that want to make a career in the application of technology will increasingly need more business-savvy.

So, should we all go back to school and get MBA’s? I view it as a tool in your toolbox. It is not a guarantee of success, but it is something that can make the path easier. Having long term career goals and a clear idea on what it will take to achieve them is probably far more important. Some companies may look highly on MBAs in making personnel decisions, others may not. Those are all factors to consider.

The other thing I wanted to comment on is the fact that many (IT) people lamented that EA isn’t part of the MBA program. I don’t agree with this at all. It’s a business degree, and like it or not, EA is still viewed as a technology discipline, not a business discipline. I do believe, however, that MBA programs should include some aspect of technology management. If an MBA prepares you to be a CEO, shouldn’t you have some idea on what your CIO and CTO should be doing?

As for me, getting an MBA is on my radar, but I haven’t yet made a decision on it. I definitely am reading more business strategy books, and for now, I think that’s the right approach for me, as frankly, I’m more concerned about paying for my kids’ education than financing continuing my own. But if I were in college today, given what I have learned about my interests in applying technology rather than building technology, I would definitely take that path, combined with a technology degree.

Yesterday afternoon, I was involved with a discussion around EA 201x. The conversation began at a lunch meeting I had with Mike Rollings (@mikerollings) of Burton Group/Gartner, and continued on with Brenda Michelson (@bmichelson) of Elemental Links and fellow EA Chris Bird (@seabird20), among others. Near the end of the conversation, Chris asked the question, “Are Enterprise Architects really Enterprise Archivists?” Brenda responded that we really need Enterprise Activists focused on action, delivery, ideation, and evangelism.

The more I thought about this, the more I love the picture that is painted by this. An archivist is essentially a librarian, and unfortunately, there are probably many EA teams that fall into this category. I’m sure there are probably many CIO’s who also think this is exactly what EA should be doing: managing the list of approved technologies, standards, etc. That is a necessary activity, but is it really what your EA team should have as its primary purpose?

Now, think about the activist. Put aside any negative connotations associated with political activists and judicial activist, and focus on the pure definition, which is someone who engages in activism. Merriam-Webster defines activism as “a doctrine or practice that emphasizes direct vigorous action especially in support of or opposition to one side of a controversial issue.” So, enterprise activism, or enterprise architecture activism, should be direct, vigorous action in support of the architecture of the enterprise. Anyone who has worked in big IT also knows that there’s no shortage of politics and tension between enterprise views versus project views, strategic views versus tactical views, so I think it fits the “controversial” term as well.

Brenda’s comments about seeing action, delivery, ideation, and evangelism hits the mark.

• Action: The action is engagement. Talk to the people that have the ability to make change happen. Using the activism analogy, the EA is the lobbyist. Engage the stakeholders, and make your case.
• Delivery: Deliver the strategic architecture, and then work with the project teams to make sure the architecture is realized properly. If you’re only cataloging what other people have done, you’re an archivist.
• Ideation: Think about the future. James McGovern (@mcgoverntheory), a fellow EA, had posted once that EA’s need to have time to think. This is where the ideas come from, and then can get turned into the strategic architecture. They’re not the exclusive source of ideas, but EA’s are supposed to be your senior level thinkers, so innovative ideas should be expected of them.
• Evangelism: How can you be an activist without being active? Make the cause known. If the cause isn’t heard, work to understand why, and tweak the message accordingly.

Just writing this up actually has cause me to think about some things that I can improve on in my own role as an Enterprise Activist. While I doubt we’ll see this as a job title anytime soon, I think it’s the right vision, can help others understand the role, and can be a powerful motivator for the team.

In the Wired magazine article on the relationship between AT&T and Apple (see: Bad Connection: Inside the iPhone Network Meltdown), the author, Fred Vogelstein, presents a classic service management problem.

In the early days of the iPhone, when data usage was coming in at levels 50% higher than what AT&T projected, AT&T Senior VP Kris Renne came to Apple and asked if they could help throttle back the traffic. Apple consistently responded that they were not going to mess up the consumer experience to make the AT&T network tenable.

In this conversation, AT&T fell into the trap that many service providers do: focusing on their internal needs rather than that of the customer. Their service was failing, and the first response was to try to change the behavior of their consumers to match what their service was providing, not to change the service to what the consumer needs.

I’ve seen this happen in the enterprise. A team whose role was to deliver shared services became more focused on minimizing the number of services provided (which admittedly made their job easier) than on providing what the customers needed. As a result, frustration ensued, consumers were unhappy and were increasingly unwilling to use the services. While not the case in this situation, an even worse possibility is where that service provider is the only choice for the consumer. They become resigned to poor service, and the morale goes down.

It is very easy to fall into this trap. A move to shared services is typically driven by a desire to reduce costs, and the fewer services a team has to manage, the lower their costs can be. This cannot be done at the expense of the consumer though. First and foremost, your consumers must be happy, and consumer satisfaction must be part of the evaluation process of shared service teams. Balance that appropriately with financial goals, and you’ll be in a better position for success.

Well I’m both delighted (and relieved) to announce the publication of the 11gR1 version of the SOA Suite Developer’s Guide. As with the original version, this was jointly written by Antony Reynolds and myself; in fact in many ways this is the book that Antony and I originally intended to write, when we first put pen to paper (or finger to keypad) back in May 2007. At this point the 11gR1 version of the Oracle SOA Suite was still in the initial stages of development, with the ‘goal’ being to time the publication of the book with the release of 11gR1.

Then in early 2008 Oracle announced the acquisition of BEA, which it finalized in July; at this point future timings around the release of 11gR1 were very much up in the air. So we re-focused the book on 10gR3, of course no sooner had this been published and Oracle released 11gR1! So after a brief pause to catch our breath and restore our sanity, Anthony and I pulled out the original manuscripts and started again.

As with most books, there is a huge amount of support and effort behind the scenes. We had a great team of reviewers who provided invaluable feedback and encouragement:

• John Deeb
• Hans Forbrich
• Bill Hicks
• Marc Kelderman
• Manoj Neelapu
• ShuXuan Nie
• Hajo Normann

In addition we had great support from the SOA product management team at Oracle, and the editorial team at Packt Publishing who played a key role in keeping us on schedule!

The new book contains approximately 40% new content and is slightly larger than the original. But we made a very conscious effort to try and stop the book from getting to big, so as we introduced new content, we tried to condense (and in some cases remove) material in other areas. We hope we have the balance right, and that readers will get as much (or more) benefit from this version as they did the last.

Barnes and Noble has introduced a $149 Wi-Fi version of its Nook eReader. This has now reached a price point where I think parents may consider purchasing one for their children. Having recently moved, I know where my budget for book purchases has gone recently: kids books. This ranges from learning to read books all the way up to the several-hundred-page series books like Harry Potter and Percy Jackson. While there’s no easy way to get all of these existing books onto an eReader (I think demand would shoot into the stratosphere if there was), there’s certainly no shortage of new book purchases in the future, either. So what would make a great kids eReader?

First, I think existing eReaders like the Nook or Kindle are probably fine for the Harry Potter/Percy Jackson age group, say 9 and up. They should have no problem using the device, it’s more a question of taking care of the device. For the under 6 age group, I don’t think current eInk screens are going to provide the right amount of visual stimulation, so at best, it’s probably a device best used while your child is in your lap and you’re reading to them. They’ll pick up the interface of the device, and be ready to go when they reach the chapter book stage of reading. The 7-8 age group is the trickier one. It’s going to get thrown into a school backpack, have who knows what smeared all of it from their hands, etc., so you get the point. The device needs to be of equivalent durability to a Nintendo DS. Most 7-8 year olds I know have one of these.

In terms of features, I think Barnes and Noble has it right with the WiFi only. The kids aren’t going to be purchasing books in airports- it’s a reading device. I’d even be okay with a device that only allows USB sync, but since I wouldn’t expect the removal of WiFi to change the price point, I’d rather have it than not. If you can give me a $100 price point with sync only capabilities, like an iPod Nano or Shuffle, even better. Purchasing from the device would need to be disabled at the discretion of the parent, especially with the one-click purchase approach of the Kindle. As a parent, I would prefer to go to a website, make the purchase, and then choose to deliver to my kids’ devices when they connect. Add in date-based delivery options, and friends and family could purchase presents that automatically show up on the kids’ birthdays, or we could even have link in to the North Pole and allow Santa to deliver them to the device on Christmas morning. eInk-based screens are a must, because the kids will forget to charge the device, so battery life is critical. Finally, we must be able to share books across multiple devices. I don’t want to have to buy separate copies of the latest book by Rick Riordan for each device, as my kids share the books now.

The real question is whether a dedicated device makes sense for your children. I think we’re looking at an age group of 7-11. From 12 and up, there’s a good chance your child will have an iPad/Netbook/Tablet/Laptop of their own with a screen space suitable for reading. Does the independent eReader get put on the shelf at that point? I know I have stopped using my Kindle now that I have the Kindle app on my iPad. Personally, I think the answer to the question is still yes, even if only used for 5 years from ages 7 to 11. 5 years for any electronic device is a pretty good life span. We spend $150 on a NintendoDS for probably 5 years of use, why wouldn’t we do the same for an eReader with more educational value? As long as there’s a software version of the reader for the multi-purpose device, all their books can go with them.

The final piece of the puzzle would be to have Scholastic tie their school book programs into this. Parents should be able to purchase for any eReader from their website and have it tie into the classroom or school fund raising programs that they offer. While the vertically-integrated device and store models of Amazon and Barnes and Noble probably won’t allow purchases for other devices, a publisher-owned store should.

A challenge for virtually any position with “Enterprise” in the title, but especially so with Enterprise Architecture, is to continually show that they are adding value to the organization. Why? Because typically enterprise architects are not directly associated with delivery. In most IT organizations, things get delivered through projects, and enterprise architects don’t typically play the role of project architect. At best, there is an indirect association with delivery.

First off, the organization must understand that there is a need in the organization for non-project activities. It’s funny how there’s plenty of positions outside of IT that have indirect relationships to business delivery, so it’s still a bit surprising that there is still resistance toward Enterprise Architecture in many organizations. This post isn’t about how to convince management of the need for Enterprise Architecture, though. It’s about the two paths that you can go once you have that management support.

The first path is all about enforcement. Someone in senior management is upset about the decisions that are being made on projects, and as a result, they put a police force in place to review project activities. That police force is Enterprise Architecture. A personal pet peeve of mine is when the police force is put in place, but the laws are not. When that happens, project teams are at the mercy of the individual that is reviewing the project and whatever their personal interests are. Those personal interests may have nothing to do with what senior management wants, or what the project team is tasked to do. If you’re going to put a police force in place, you first need to have laws. Anyway, the point of this is that a police force approach can result in a lot of animosity. On the plus side, Enterprise Architecture does get visibility into all projects with the power to influence their direction. Also, sometime it is necessary to put a police force with a very big stick in place to force some change on an organization, but it does so at the expense of corporate culture and can result in a lot of ill will.

How do you avoid this? By remembering that as an enterprise architect, your role is not to audit, but to assist. Everything you do should be done with the thinking that your are helping to deliver, helping people to make good decisions, and helping to make their job easier, not more difficult. If you take this approach, you may still have to review projects, but your focus should be much more on communication, education, and evangelism. If you are setting standards, you should be communicating the standards, the justification for them, and the expected results to see when they are followed. If those results aren’t achieved, you should be working with the teams to understand why and get them back on the right path. Another pet peeve of mine is when someone says, “No, you can’t do that” but fails to follow up with instructions on what the right way is.

In short, if you are in a role that is normally not assigned to project teams, you must remember that you are still part of the delivery team, and everything you do should contribute to the successful delivery of a solution that meets the goals of the project and the goals of the business. It’s about being helpful, not a hinderance.

Blogger: Richard Watson

Regular readers of this blog will know I've been conducting and writing about an extensive field research into business process management (BPM). Before we started this field research, all we could hear about BPM in the industry was great news! Universal acclaim abounded for this BPM thing from Vendors, journalists and indeed analysts …

"… good reasons for adopting BPM: BPM is an ROI winner; BPM works; BPM is about standardizing business processes; BPM complements many other enterprise software initiatives; BPM can be fun." – Ann All, IT Business Edge, reporting Joerg Heistermann, US CEO of IDS Scheer

"…many larger companies are appreciating the direct business value of BPM projects" – Stefan Reid, Forrester Senior Analyst

"The wedding of BPM and SOA was forecast for a number of years. These days it appears the marriage is working." - Colleen Frye, SearchSOA.com

With this kind of hype in the air, we were skeptical and wanted to find out the true situation.  Nobody talks much about the challenges of getting value from BPM.  We didn't know anyone experiencing this kind of ROI.

So, what did we do? We talked to people leading BPM initiatives. Open-ended discussions with 35 business and IT leaders representing 21 organizations revealed complex and subtly differing opinions on BPM.

What did we find?  The core finding statement of the study is:

BPM is valuable and it does deliver measurable return, but organizations are not getting this return from BPM because:

•They do not understand BPM

•They are too focused on BPM infrastructure

•They are succeeding with tactical projects

•They struggle with culture change required

Join me (Burton Group subscription required) for a 60 minute webinar at the following times in May to discuss the field research process, the 12 key findings that underpin this statement, and their implications for your BPM program:

Tuesday, May 4, 2010
2:00 p.m. EDT/11:00 a.m. PDT/18:00 UTC GMT/20:00 CEST

Wednesday, May 5, 2010
9:00 a.m. EDT/6:00 a.m. PDT/13:00 UTC GMT/15:00 CEST

You can register (clients only) for the TeleBriefing here.

If you are not a Burton Group client, or if you cannot attend either sessions, I’ll also be sharing the findings at our Catalyst User conferences: in Prague 21-24 June, and in San Diego in 26-30 July.

Related posts:

Stories from the BPM trenches
Six BPMs and the elephant
What
do the prices of exotic vegetables say about your BPM initiative?

What looks to be a very simple question is actually a very tough one. The answer to this is of particular importance to a domain architecture team (a team whose scope is larger than a single project or solution), but the principles apply even to a solution architect. The solution architect has a slight advantage that they’re typically working with a team that has a single common goal: deliver the solution. Domain architects, however, must balance the delivery focus of project teams with setting the stage for systemic success across a broader portfolio of solutions, be it within a line of business or across the entire enterprise.

To me, architecture is about creating a categorization that establishes boundaries. These boundaries partition the solution into different areas. What’s the most frequent reason for partitioning? To create areas of responsibility. Within a project, your break things down to a sufficient level in order to be able to hand off units of work to individual developers or engineers, who now have responsibility for delivering that work. The biggest challenge is where those units of work overlap. When thinking of the typical Visio diagrams associated with architecture, this type of view is consistent with a boxes and lines view. We’re interested in what the boxes are and what’s on the lines (the interfaces and messages) that connect them.

While this boxes, lines, and responsibility approach works for both project and domain architects, there is one big, significant difference: the timeframe of responsibility. Once a project has been delivered, the development responsibilities typically go away. Your decisions on how partition the project are solely based on getting it delivered. A domain architect, however, is interested the full lifecycle of responsibility for a component. It’s not just the initial development, but it’s the ongoing care and feeding, the onboarding of new consumers, etc. If we don’t partition things to support future change, the pain involved in supporting that change will be high. The desire to partition things to allow for an efficiently managed portfolio may not be the same partitioning that allows for the most efficient development. These needs have to be balanced. In the perfect world, the partitioning for portfolio management could occur outside the context of any project, allowing the “optimal” partitioning to be used as an input by the project architect to balance these needs. In reality, that context doesn’t exist, and we’re doing our best to build it as we go along.

This type of approach can be challenging for domain architects when many people have the perception that the architect is the nuts and bolts person, looking at how things are built, rather than what gets built. That’s because many architects have gotten there by being a senior developer or engineer. I’m not suggesting that the “how” portion isn’t important, especially because the “how” decisions also have a lot to do with partitioning, but the “what” is increasingly important, because that ultimately defines what must be managed for the long term. If those units are difficult to change over time because of poor partitioning from a responsibility and ownership viewpoint, it will be a struggle.

What are your thoughts on what things are architecturally significant?

With the announcement of docs.com on Wednesday from Microsoft, it got me thinking about what I’ll call the consumer cloud. As my iPhone has become a critical device for me, and I expect my iPad 3G to do the same when it arrives on 4/30, I find myself longing for better use of the cloud for my information. The simplest example is the iTunes tether. I listen to quite a few podcasts, and I have a script set up every night on my MacBook Pro to download the latest podcasts and then sync my iPhone, so they’re ready for my drive in to work in the morning. It’s a big problem when I travel, though, because the iPhone only knows about the podcasts that have episodes, and for feeds that don’t exist in iTunes, like my personal playlist for IT Conversations, I have no way of downloading new episodes without the tether to my MacBook. With my iPad on the way, I expect that the need for a cloud repository will grow even more. Some tools provide their own cloud-based storage, like Evernote. There are cloud repositories or syncing utilities like DropBox, MobileMe, and Box.Net, but so far, the integration with the content editing or viewing tools isn’t there, in my opinion. That’s especially surprising with MobileMe, at least for the iPhone.

These needs are what makes Microsoft’s announcement so interesting. Ironically, even Apple showed a hint of recognizing the power of Facebook in the recent “dog” iPhone ad. When they discussed sharing pictures in the commercial, they weren’t shared via MobileMe, they were shared via Facebook. If Facebook becomes the de facto place for sharing, does that make it the de facto cloud storage solution for the consumer segment? It arguably is already doing that for photos. My brief visit to docs.com emphasized Facebook’s role in access control more so than actually storing the documents, but at that point, Facebook is still the gatekeeper. With the enormous community that Facebook has, it will be interesting to see what happens to things like MobileMe. What is clear is that Facebook is in the driver’s seat, and everyone else is either chasing them or hopping aboard the Facebook bus.

Blogger: Kirk Knoernschild

Just a few days after the iPad became publicly available, Apple has rocked the world again with their iPhone OS 4.0 announcement yesterday. iPhone, and now iPad, users got what they wanted as the new OS is packed with new and interesting features. But the OS announcement isn't what rocked the world.

New Licensing Restrictions

Apple also made some changes to their developer agreement. In short, Apple does not seem to appreciate development frameworks that allow developers to create iPhone applications using an intermediary framework. It's pretty clear they want developers using Apple tools.

As far as I'm aware, John Gruber broke the news on this one, and provides a great overview. While this spells trouble for Adobe's new Flash-to-iPhone compiler, Adobe is not the only organization looking to make iPhone development easier. There are an abundance of other vendors and products for whom this change to the developer agreement may spell trouble for.

The language in the new agreement reads:

If I interpret this correctly (and it seems pretty clear), it appears that developers must use C, C++ or Objective-C to develop the application. And Apple will easily be able to recognize if a third-party framework was used, since many embed the framework and container into the application to serve as an intermediary component between the application and iPhone OS.

Market Impact

In an upcoming Burton Group market profile on mobile application development platforms, we make a point to talk about the burgeoning vendor market that is emerging to address the challenge of creating cross platform rich mobile applications. These changes to the developer agreement sends a crushing blow to this burgeoning market.

If you're an iPhone developer out there who currently uses Objective-C, you're jumping for joy today. Your stock just went up. If you're a consumer, with the plethora of high quality applications already available in the App Store, it's likely the impact is negligible. If you're an enterprise hoping to leverage a vendor solution to develop cross-platform mobile applications, make sure you do your homework in evaluating their products. Some, possibly many, already violate the new terms of the Apple iPhone OS 4 developer agreement, meaning the applications you develop using their solutions will be rejected by Apple once iPhone OS 4 is available.