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.

I saw a tweet today, and while I don’t remember it exactly, it went something like this: “You must be successful with SOA to be successful with the cloud.” My first thought was to write up a blog about the differences between infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS) and how they each relate to SOA until I realized that I wrote exactly that article a while ago as part of my “Ask the Expert” column on SearchSOA.com. I encourage you to read that article, but I quickly thought of another angle on this that I wanted to present here.

What’s the first vendor that comes to mind when you hear the words “cloud computing”? I’m sure someone’s done a survey, but since I don’t work for a research and analysis firm, I can only give you my opinion. For me, it’s Amazon. For the most part, Amazon is an infrastructure as a service provider. So does your success in using Amazon for IaaS have anything to do with your success with SOA? Probably not, however, Amazon’s success at being an IaaS provider has everything to do with SOA.

I’ve blogged previously about the relationship between ITIL/ITSM and SOA, but they still come from very different backgrounds, ITIL/ITSM being from an IT Operations point of view, and SOA being from an application development point of view. Ask an ITIL practitioner about services and you’re likely to hear “service desk” and “tickets” but not so likely to hear “API” or “interface” (although the DevOps movement is certainly changing this). Ask a developer about services and you’re likely to hear “API,” “interface,” or “REST” and probably very unlikely to hear “service desk” or “tickets”. So, why then does Amazon’s IaaS offering, something that clearly aligns better with IT operations, have everything to do with SOA?

To use Amazon’s services, you don’t call the service desk and get a ticket filed. Instead, you invoke a service via an API. That’s SOA thinking. This was brought to light in the infamous rant by Steve Yegge. While there’s a lot in that rant, one nugget of information he shared about his time at Amazon was that Jeff Bezos issued a mandate declaring that all teams will henceforth expose their data and functionality through service interfaces. Sometimes it takes a mandate to make this type of thinking happen, but it’s hard to argue with the results. While some people will still say there’s a long way to go in supporting “enterprise” customers, how can anyone not call what they’ve done a success?

So, getting back to your organization and your success, if there’s one message I would hope you take away from this, it is to remove the barriers. There are reasons that service desks and ticketing systems exist, but the number one factor has to be about serving your customers. If those systems make it inefficient for your customers, they need to get fixed. In my book on SOA Governance, I stated that the best way to be successful is to make the desired path the path of least resistance. There is very little resistance to using the Amazon APIs. Can the same be said of your own services? Sometime we create barriers by the actions we fail to take. By not exposing functionality as a service because your application could just do it all internally, in-process, we create a barrier. Then, when someone else needs it, the path of least resistance winds up being to replicate data, write their own implementation, or anything other than what we’d really like to see. Do you need to be successful with SOA to be successful with the cloud? Not necessarily, but if your organization embraces services-thinking, I think you’ll be positioning for greater success than without it.

An article titled "Solving the SOA
Governance puzzle: Taking a "Bite-Sized" approach" authored by Oracle’s Jyothi Swaroop was published as the
cover story in the December issue of Service Technology Magazine.

Abstract:
SOA Governance initiatives help organizations optimize their service-oriented architecture (SOA) by providing a means to reduce risk, maintain business alignment and show the business value of SOA investments. But all too often these initiatives can be seen as daunting projects that are overly broad and complex, require too many resources and are too time consuming.  In this article, Oracle’s Jyothi Swaroop will explain how organizations can take an incremental approach to SOA governance initiatives to meet their specific needs. This will include an overview of how SOA governance technologies can support specific tactical level projects and yet ensure the organization is able to optimize the entire lifecycle of its SOA.

Read the complete article

On the Forrester Enterprise Architecture Community site, Randy Heffner asked the question, “What should EA do for business agility?” In my two responses in the discussion, I emphasized that EA is all about decision support. Yes, you may create a future state roadmap, but what the organization winds up with is completely dependent on what projects the organization decides to execute, and then on how those efforts are executed. EA influences those decisions, but we’re not the ones making them.

So why is this post titled, “Deciding ‘Yes’ on EA”? In that same discussion, William El Kaim added the following:

Let me be real provocative, and state: EA is dead … It has been killed by architect themselves leaving in their ivory tower and their beautiful EA drawing tool that nobody uses and that contains outdated data when they are published.

You can read the rest of what William had to say on the Forrester site, but I don’t think it’s anything any of us practicing EA’s haven’t heard before. But there’s a very important point in William’s statement. If nobody uses what EA produces but EA themselves, that’s a big problem. Put simply, if we provide poor decision support, the organization will ultimately decide against EA.

Like most things in this world, there are far more ways to fail than there are to succeed. So what are some best practices for providing excellent decision support so that the organization will decide “yes” on EA?

1. Figure out who makes the decisions. Sounds simple, right? Not quite. I’d love to see a Forrester or Gartner survey on this one, but I’m willing to clarity and consistency on the decision making process is not a strength for most organizations. Regardless of the state of your decision making process, if you don’t have access to the people making the decisions, you have little to no chance of influencing them.
2. Figure out how they make their decisions. Note that I didn’t add, “and make them better.” Remember that they’re the one making the decisions, not you. Your role is to give them added information so that they can make the best decisions possible. In some cases, the whole reason for having the discussion may be so you can learn and incorporate that decision maker’s information into your guidance for other decision makers.
3. Make your information relevant to them. Don’t give them a bunch of models that are only meaningful to another EA. In the case of upward decisions, this usually means that the architecture implications have to have financial ties, or clearly alignment with business objectives. I’ve had success using capabilities in these discussions, and I think the current research would back that up. You must tailor your information to their needs. If they don’t understand it, it’s your problem, not theirs. They’re making the decision, not you.
4. Emphasize added insight, not oversight. This is very important for interactions with project teams. All too often, EA is positioned as the enforcer. Come before the review board and we shall assess your worthiness. I’m sorry, but a guy who spends 80% of his time writing code each day should be far more aware of the latest frameworks than the average EA. The role of the EA is bring enterprise and/or domain perspective to the effort. As soon as the project gets established, the project blinders go up, and it’s the job of EA to remove those blinders and add enterprise insight into the effort.
5. Don’t rely solely on artifacts, and where you must, make sure they are easily digestible. While many factors in an organization lead us toward email-based interactions of documents, try to have a face-to-face conversation about the guidance whenever possible. At a minimum, by walking someone through it, you at least knowing they’re actually reading some part of it. When you create the artifacts, get them to the point.
6. Be cautious about consulting models for EA.A consulting model for EA is great, right? When someone needs more information to make a decision, what do they do? They hire a consultant. So EA should be internal consultants, right? Well, not really. That may work in the short term, but it is a “I’m here when you need me” model, when you really want to always be a part of the process. Don’t turn down the consulting approach, as it can get your foot in the door, but make sure you turn it to something more systemic.

What other best practices (or worst practices) do you recommend in firmly establishing EA as a valuable resource in the decision making processes in the organization?

Here’s an excerpt from a very interesting article on CIO update titled "Finding the value in SOA" by Stephen Bennett of Oracle

"Because of this, SOA must not be seen as a solution development approach that starts and ends once a solution is delivered. It must be seen as an on-going process that, when coupled with a strategic framework, can change and evolve with the business over time. Unfortunately, many enterprises adopt SOA without utilizing a strategic framework, causing a host of challenges for their business.

Just a few of the challenges I have seen include:

• More complexity and moving parts
• Increased costs
• Projects taking longer than before
• Solutions more fragile than ever
• Little or no agility
• Difficulty identifying and discovering services
• Exponentially growing governance challenges
• Limited service re-use
• Duplication of effort leading to service sprawl
• Multiple siloed technology focused SOAs
• Funding for service oriented projects being cut"

Read the complete article

I know that it has been a long time since my last post, just though that I would update you my latest thoughts of Governance.

I just recently completed an executive round table series on EA and Cloud in Singapore, Indonesia and Malaysia. The response was phenomenal. The key point of the session was that Enterprise is the key enabler of innovation – All companies want to drive to be market leaders, EA can lay the foundation for the path to deliver that at innovation.

When it comes to innovation, I see two distinct types:
(a) Passive innovation is where a company creates innovation thought increments improvement over time. A great example is when airlines went from paper tickets to electronic ticket. Next logical progression is to do the same with boarding passes. There are a lot of examples to choose from, thought the thing to keep in mind, is that passive innovation will only keep you in the lead, it won’t allow you to create new markets or jump from #3 to #1 in one go. For that we need another type of innovation.

(b) Disruptive innovation is where you create market where none existed before. Thought very difficult to do and requires significant investment in research, product and software development and not least of all, visionary thinking and timing, if done correctly, can turn the world on it’s ear. A great example is Apple iTunes. Some might say that this is incremental innovation, but only in one aspect, the downloading of music. Other then that, it’s all disruptive innovation. Being able to buy a single song rather then the album fundamentally changed the way we get out music.

Behind all of these types of innovation is Enterprise Architecture. EA creates the infrastructure foundation, then delivery systems and the end-user experience to deliver this innovation.

At Oracle, we are driving that EA innovation with our private cloud offerings from “bolt-to-glass” as I like to say. For more on what Oracle has to offer in EA and cloud, have a look at Cloud Computing | Oracle and Enterprise Architecture – Oracle

I am working on new material that I will be posting in a couple of weeks, so check back regularly for new updates or feel free to subscript for updates.

Oracle Enterprise Manager SOA Management Pack EE is the ONLY solution available in the market that can help you assess the business impact of transaction anomalies and fix hung transactions. Watch this demo on Oracle’s Business Transaction Management to learn how.

Here’s a video of how Delta Dental of Michigan streamlined their IT with Oracle SOA Suite, Weblogic and Webcenter technologies.

Cloud computing is changing how enterprises look at end-to-end IT operations. As cloud adoption soars, CIOs want to “police the cloud” to ensure business-critical manageability and governance. IDN ‘Expert Voices’ speaks with Cathy Lippert, Director of Oracle SOA Governance, to learn how SOA Governance is being tuned for Cloud Governance, including security, policy compliance and even SLAs.

View the podcast and download slides