SOA Manifesto Value Statement Critique

Looks like the SOA Manifesto went public recently. I wasn’t invited to participate, so what does one do when not invited to a party? It’s quite obvious—you tell everyone how bad the party was, right? Ahh, High School memories revisited… Any case, I commend the community for coming together to vet through definitions, principles, and value statements (Heck, Even the SOA is Dead blogger was there, which I find really ironic.) However, I feel a few key points were missed and below are my critiques of the 6 value statements. Keep in mind that my critiques aren’t intended to poke holes in the value statements just due to my lack of involvement; rather, I truly found the value statement to be confusing, not accurate, and a few that are a lot broader than just SOA. I tried to put myself in the shoes of a SOA newbie who is using this to grasp SOA for the first time, and therefore felt obligated to point out areas that could use improvement. I truly hope this is constructive and maybe we see a 2nd version of the manifesto that incorporates this feedback (how Agile would that be?). Please call me and I’m more than willing to help. I love parties!

Value Statement Critique

#1 Business value over technical strategy. This was easily my favorite value statement. In my own Blog, I called it Business Visibility and Understanding over IT Priorities. Clearly, everyone must agree that our goal is to create business solutions. Conclusion: Great statement! The business does always come first! That’s why we’re here!

#2 Strategic goals over project-specific benefits. I am not sure I can agree with this value statement in the fact that I don’t always believe that strategic goals trump project specific benefits. My feeling is if you take this philosophy, you may never get your SOA project started or out of the gates. My rationale is that in order to get SOA funded and jumpstarted, you need to produce something that is demonstratable and appealing to the business, in a very rapid implementation. How else do you get initial buy-in? My feeling is that (1) this value statement is more academic than practical (2) this value statement is also a lot broader than just SOA…So I am compelled to proclaim, Isn't this what the original Agile manifesto is supposed to avoid-- academic principles that are difficult to follow in practice and too abstract to actually leverage?? I think there could have been a more SOA-specific statement in here, while this is more Enterprise Architecture, touchy-feely. Conclusion: I love the idea of everything being strategic (we don’t like tactical), but not sure this will statement work (especially in this economic climate!). Isn’t this what made SOA Dead? Now, do I think one should ignore strategy? No, there is certainly an overarching strategy and vision to work towards something greater and more holistic along the SOA Roadmap; however, I do think SOA needs to start from the ground-up to gain proper momentum and business-level buy-in and the only way to accomplish this is through incremental project implementations that have a discrete goal, are demonstrable, and appealing to the business.

# 3 Intrinsic interoperability over custom integration. I have mixed emotions on this value statement. I believe interoperability is one of the leading principles of SOA, but I also think it’s a bit confusing to have that value prioritized over "custom integration". I don’t think we are comparing Apples to Apples here. I think a better wording of this statement would have been "interoperability over individual silo's"...in my blog I stated "integrated systems, processes, and people over individual silo's". The problem with the "custom integration" wording in this statement is most legacy systems require custom integration in order to make them interoperable! Not everything is component-driven, plug and play or "configuration driven design", which to me are the opposite of "custom integration". I’ve seen a lot of custom integration in SOA, and it was required for the proper transformation of the system. Conclusion: I like the first part of the statement (Interoperability rules!), but find the second part to be inaccurate and confusing.

#4: Shared services over specific-purpose implementations. I do like the concept of Shared Services, as I find re-usability one of the leading principles in SOA. Again, I'm not in love with the 2nd half of this statement, as I'm not sure it is accurate. I feel very strongly that there are many specific-purpose objects in SOA architecture and required throughout the implementations and design. Not every service is going to be a Shared Service or a Business Service. For example, data services or IT services are usually very specific to the system they are interfacing with or rule they are enforcing. Take any data service that is part of the CRUD model on a legacy database—is that a shared service or a specific purpose implementation? Conclusion: I like the idea and whish everything could be reusable, but don’t want to undervalue services that are not!

#5 Flexibility over optimization. This statement gave me the most heartburn. Simply put, I don't agree with this statement. I believe flexibility and optimization are mutually exclusive and therefore one should not be valued over the other. How can you value one over the other? It’s been very clear to me that some services could be static but value optimization more than flexibility. For example,
A high speed transaction in a Financial Services business process would value optimization much more than flexibility. I feel a more appropriate wording of this statement would have been “Flexibility over rigor”. This I can agree with that agility and adaptability are leading principles. But, so is business process optimization. Let’s not forget software engineers, that there is always a trade-off of performance vs. agility in software programming and at the end of the day, some applications (and services) need more speed and acceleration over flexibility and agility. It is always a case-by-case basis. Conclusion: Misleading prioritization. Would really like to see this re-worded and re-released to clarify.

#6 Evolutionary refinement over pursuit of initial perfection I like this statement, as it enforces the iterative nature of "Agile lifecycle and management" and leads one to believe that an early feedback cycle will be incorporated. However, I have to ask, is this principle really specific to SOA? Isn't this just a re-hash of Agile Principle #12? Conclusion: Love this value statement, as I think iterative, early feedback is the way to go, but I think this statement applies to more than just SOA-- any project being implemented should follow this statement, and therefore I diminish the value of this statement only because I feel we heard this before in the Agile Manifesto.

Flying in the Clouds requires many levels of TRUST

I have been fortunate to present introductory concepts and practices in Cloud Computing at 3 different conferences of late. The audience is very active, usually about 50 attendees in the room. However, it's very interesting that every time I poll the audience on who has used cloud services or a cloud provider, I usually get anywhere from 0-1 hands raised. It seems most folks are still feeling out cloud and a lot of it has to do with an overall lack of trust.

I receive a lot of questions on security and data ownership concerns throughout my presentations, but one in particular struck me as a great discussion point. Right when I was building confidence that I had all the answers to everything anyone wanted to know about Cloud, a question got asked that really got me thinking more about cloud and the requirement for TRUST. This particular person simply asked: “What do you do to prevent Cloud employees, particular Administrators with System level access, from jeopardizing or leaking your company’s sensitive information”? It’s a very pertinent question, and although there is no silver bullet solution, the answer ultimately relies on TRUST. If you are going to implement in the Cloud, you must have multiple levels of TRUST. After all, you’re putting protected (and potentially sensitive) company information in the hands of others, and that in itself takes a lot of TRUST. The answer to the questions asked-- you need to trust your provider just the same as you trust your employees (Do you trust your employees?) It's important to follow some of the practices below to help solidify trust in your cloud provider:

(1) Choose your cloud providing vendor wisely. If you don’t TRUST your cloud provider, then you won’t sleep at night. If data ownership and security will bother you to no avail, then you might not be ready for the cloud and using a provider. You must pick a vendor you TRUST to protect your must sensitive information. Do you TRUST your spouse? Yes, of course! This same level of TRUST must exist for your Cloud provider; otherwise you could be doomed for an early divorce. Make sure to meet your Cloud Provider face to face so that you know them well. Interview your Cloud provider. Interview your Cloud provider’s employees. Treat your provider’s employees it as if you’re hiring their employees, because they are now part of your “team”. You need to equally TRUST them as if they were your own, because the will have the same access and privileges. Make sure you have their contact info, background check results, and overall level of confidence from having met them face-to-face.
(2) Iron clad contracts. Template NDA’s are not sufficient for this new paradigm that cloud computing presents (using other people's assets). Your legal team may not be ready for cloud because legal doesn’t TRUST anyone...sorry legal! Talk to legal and explain the model, so that the contracts and non-disclosures provide adequate protection for the worst possible failure (such as sensitive data leak). This is your insurance plan, so make sure you cover your bases and have contractual stipulations to protect your cloud relationship.
(3) Stage an unannounced vulnerability test on your cloud provider. Similar to when TSA is testing airport security with their security tiger team, you can execute a mock infiltration test scenario without the cloud provider security team knowing its coming. This will help you establish the confidence and TRUST that your data and systems have the highest level of protection (unless, they fail the test…)
(4) Walk before you run. Try before you buy. Date before your marry. Don’t put the most mission critical systems or applications in the cloud until you have confidence, cultural acceptance, and level of comfort through a cloud pilot. Build the TRUST needed through incremental successes and then go for the big enchilada when you’ve reached an appropriate milestone-- i.e cloud tested, verified, and trusted.
(5) Ask for weekly or monthly performance reports that show how effective and secure the cloud provider is performing. Make them earn your TRUST through metrics , quantitative analysis, and statistics.
(6) Tour the facilities where your cloud provider will host your solution. Make sure they show you exactly where your space will be located. You need to see your hosting space in person to TRUST that will be adequate.
(7) Ask for reference qualifications. See if others TRUST the provider as well. Ask the references how they overcame their trust concerns (peer advice).
(8) Ensure there are Key Performance Indicators that are contractually tied to the performance. This includes incentives and disincentives on their Service Level Agreements. Make them perform to the level of TRUST they have committed to.
(9) Keep a contingency plan and contingency architecture in case things don’t work out in the cloud and you need to drop back to Earth. If the TRUST fails and the cloud fails, you need a back-up plan so you are not left without the infrastructure to deliver your business capabilities. Cloud is a new, so a contingency is very important.
(10) Consult with diverse set of stakeholders in your organization to get their "cloud advice". Talk with the SOA, EA, IT Architects, developers, business users to get their opinions and recommendations. Make sure a broad group is surveyed to ensure cloud decisions are not made in a vac cum.

SOA Manifesto

Since I'm presenting on Agile SOA tomorrow at the MITRE conference, I thought it appropiate to create a slide on a proposed SOA Manifesto. Let me know your feedback:

1) Architecture driven (over product driven implementation)
2) Integrated Systems, Processes, and People (over individual silo's)
3) Business Visibility and Understanding (over IT priorities)
4) Re-usability (over redundant efforts)
5) Standards and Governance (over non structure)
6) Agility and Adaptability (over non flexibility)

Boiling SOA to 3 Simple Patterns

I love SOA. There I said it! It's done more than pay my bills, it's helped me strategize robust solutions to help businesses succeed. I can't see how any organizaiton can survive without a SOA an strategy! Ok, enough with the SOA love fest. Recently, I have been discussing and debating with some of my colleagues my thought process that Services should be the foundation for anything integration. Even when Ms. Maine proclaimed “SOA is Dead”, she followed up with “long live Services”. Let me explain my rationale. I see services as used and re-used in 3 simple, high-level integration patterns and this is how services can be the foundation for anything integration:

(1) System-to-System integration. Everyone should be very familiar with this pattern. This is 90% of all integration issues. Information Sharing. Data Exchanging. Synchronizing. Hetergenous systems, businesses, applications. Getting data from point A to point B in the right format, at the right time, and with the uptmost quality. This can be real-time or batch. It can be atomic transactions or bulk data loads. All of this should be used through services! Does this mean webServices? Not necessarily, as we know for example that ETL can’t afford the overhead of HTTP and XML. Not to beat a dead horse for the SOA experts, but I think many out there still don't understand that a service isn’t necessarily a webService. What is more important than webServices is the notion of architecting and exposing Business Services that can be consumed and re-used across enterprise. Not rocket science, and most SOA-educated get this!

(2) Business Process Management. A business process should ultimately simply be the orchestration of services across an end-to-end business process during runtime execution of the process. A BPM/BPEL should map business services to each Level 1 activity in a multi-level process flow or process map. Pretty simple: each activity is a business service at Level 1. This approach enables your business process, at runtime, to reuse the same services used in system-to-system integration from Pattern #1 and be easily managed and monitored. Ultimately, you can see where I am going-- our goal is to create a single version of the truth that can be used across all 3 patterns.

(3) Composite Applications: I recommend to clients to re-think their approach to building applications and that not everything requires development or integration to the back-end or legacy systems. Instead, they can focus on developing the business rules and the front-end functionality of these user-enabled applications. No longer do they require using "legacy" techniques that create complexity and more architecture hairballs; rather, they can leverage services to simplify all the plumbing required in a typical application development lifecycle. Why build 1-off websites, dashboards, reports, or mobile applications and re-invent the wheel with all the hard work required for interfacing, security, transformation, translation without re-using services that could already exist? Your creating a bigger architecture hairball! Instead, use a “mashup approach”, and re-use the same services from pattern #1 and #2 and make your life simpler! Re-usability! Hide the complexity and consume what has been exposed! See, my approach with SOA is to untangle the hairball that exists in organizations and not create more lines of code, more interfaces, more maintenance. If we are building another interface another integration to maintain for web or portal development, we are making the hairball worse. Instead, we should be using services to mask the complexity of integrating user-facing applications to legacy systems. This will allow us to reduce and wither away the hairball.

Architect Obstacles

I've been invited to participate in a podcast next week, to discuss challenges today's IT Architects face. I would like to open up to a broader audience, please send me any of your most pressing obstacles, and I will include it in our discussions.

I've listed a few that I have experienced most recently:

• Non-Enterprise IT Dept:Individual pockets exist within the IT Dept. Even though architects exist in various areas throughout the organization, it is a disparate, federated architecture without a centralized framework. IT groups are not thinking “big picture” on how their individual kingdoms impact the greater enterprise. They are architecting in silos.
• Businesses making IT decisions. This really annoys most IT departments and for good reason-- businesses don't know technology, IT feels undermined, but the business has the money! So, everyone says you "must sell to the business", but I say "don't leave IT behind!" We have businesses buying software, consulting, and trying to do architecture without IT's input. Often times, the Line of Business decisions doesn't necessarily fit into the architecture. This is why you find organizations with 3 BPM tools, 15 SOA products, and God-knows how many web and database products. All the vendors are licking their chops to sell to business, but remember that IT has the expertise to help with standards, architecture, and to bring together enterprise-level thought processes.
• Industry and Technical Standards overload. It's funny, because some IT areas have too many standards to learn and try to digest (webServices, Security), while others have too few (i.e. Cloud Computing). Architects are confused which standards to use and when, which to ignore, and how to incorporate and apply the selected standards across their enterprise.
• Architecture not tied to a “business initiative”. Because architecture often doesn't get tied to a specific business initiative, it often gets underfunded. Many times its a foundational IT initiative, and therefore businesses believe it doesn't help improve business (increase revenues)...This frustration is often a failure of the architecture team itself-- they have failed to show a direct linkage to benefits, and now can't prove their value. To their defense, that's not always easy task, but it must get done to validate their initiatives and ultimately prove their existence. Architecture is important, necessary, and should not be ignored-- but can quickly be undervalued or under appreciated by the rest of the organization.
• Educating stakeholders This is one of the most frustrating aspects of the Architects job. They need to teach others the importance of Enterprise Architecture, SOA, Cloud, etc. If you think architects are challenged educating their Line of Business on what architecture is, but guess what-- not everyone in IT “get it” either. That is why you always see the architects so stressed and pulling their hair out :-)
• Commoditization Many folks across the organization just assume architecture gets done and most don't even know it gets done. It's like when you move into a house, many of us don't appreciate all the work that went into building the house, all they way from digging the dirt to framing the house-- we only lavish at the beautiful bathrooms and granite counter tops. We don't see all the labor that occurred underneath. This is the same for users of software-- we only appreciate the end product and if the web page or dashboard looks nice. Certain things are expected to be there and to always work-- like a commodity. Therefore architecture team receives minimal respect and little patience from stakeholders and customers. Rarely does anyone know about all the blood, sweat, and tears that went into building and architecting the system from scratch!

Overcoming SOA Intimidation

This blog has been on ferlough for some time, but is now returning to its reguraly scheduled broadcasting.

Talking with customers, I am realizing how intimidating starting an SOA project is. So many capabilities to deploy, so many products, so many acronyms, so many standards, so many industry initiatives, so many vendors-- where does one get started? I often recomend starting with an SOA pilot, prove success, build momentum, win over the hearts and souls of colleagues, let some semblance of inertia occur, and away you go on your SOA Journey. Then the question ultimately arises of how to choose your first SOA Pilot and criteria for doing so-- this will be discussed in subsequent blog.

So, how does one overcome their SOA fears?

1) Education. Get a good baseline understanding of what SOA is and what it entails. I spend a lot of my time in this area making sure my customers "get it" and comprehend the big picture, all the corresponding principles and practices, and practical applications of the SOA theories. Hire an industry expert to come in or attend a Boot Camp to get educated on what SOA is.

2) Take a Step towards the ledge. Dive In! The best way to learn, is to try. Engage in an SOA pilot. Give it a shot-- choose something rapid and quick that you won't lose your shirt on if it doesn't meet your expectations or fully succeed. You have to get off the sidelines if you want to be a player!

3) Hire a consultancy. Really, if you don't know what your doing, get an expert to help. How many companies implemented SAP or Oracle on their own? Let the experts help. Everyone is touting they know SOA, so certainly be selective in who you choose. It's the notion of specialization-- would you try to build a house by yourself? No, you don't have the time, expertise, or resources to do it. Also, many times your opinions and forsight can be narrow, and hiring outside help will give a good 3rd-party opinion. You want your first project to go right, so make the right investment.

4) Talk with Others. Ask your friends, family, neighbors how they implemented SOA. You can network at a conference (if you can avoid all the vendors...) but engage in open dialouge. Understand what went right, but more importantly, what went wrong with other experiences.

5) Don't go by (or buy) the book. All the SOA books I've read are very academic, and are great for reference, obtaining deep knowledge, and helping you to fall asleep at night. You need the cliff notes to get started! Who has time to read a 400 page book before engaging on their SOA Journey? What customers need is a cookbook, and that just doesn't exist (hmm...maybe a good idea for a book? SOA Cookbook, coming to a Barnes and Noble near you). There is plenty of reference material on the Internet, but certainly there are products out there that will help you create webServices, XML, process models, composite applications without having to filter through the SOA academia.

SOA Product Requests Beyond the Sun acquisition

With the Oracle-Sun acquisition, a lot of chatter about Java, mySQL, and Open Source projects and questions abound about product roadmap, among a lot of other things being asked. Since my focal area is SOA and middleware, I'm a bit curious on how the acquisition will impact the Oracle SOA Product roadmap. The latest Oracle SOA product roadmaps seemed to be a step in the right direction, so we certainly were pleased with the promised direction-- most of the OSB being based on AquaLogic. Now, there will be 2 additions to the "Oracle SOA Family" from Sun-- Java CAPS and Glassfish. CAPs contains much of the product from when Sun acquired SeeBeyond a few years back, and Glassfish has a cult-like open source following for their ESB and Application Server offerings. Both are heavy on the ESB capabilities, but I find it really hard to think Oracle will shift product direction again on the Oracle Service Bus, since they finally paired down on the product road map. Pure speculation, but I predict a sunset (no pun intended) of the Sun CAPS ESB, a survival of Glassfish App Server, and I'm mixed on whether Glassfish ESB will survive-- back me into a corner and I'd say probably not.

Some short-term Oracle SOA areas that I think would benefit from increased investments (my personal wish list?):

Registry/Repository: Oracle was OEM'ing HP Systinet but is moving towards AquaLogic Registry Repository. This may be more of a marketing issue, but whenever I talk to prospects and clients, I often times hear other vendors mentioned before Oracle SOA Governance (ALRR) and these vendors are lower on the Magic Quadrant! I think the governance tools are taking on equal importance as the ESB as a "must have SOA tool". I'd like to see Oracle begin pushing this as a flagship SOA product in addition to the OSB.

Improved BPEL and BAM tool. This tool needs to get out of JDeveloper land and really become a true Business Analyst tool. Right now, the learning curve is a bit too much for a typical BA or "non-techie". I do see the potential here with the current products, just needs to have a more business analyst feel for capturing functional requirements.

Mash-up and Composite Application Tooling: I would like to see Oracle combine APEX with a mash-up platform to create improved rapid applications. Maybe hook into Google Apps or Yahoo Pipes? APEX has been a little clunky on handling webServices, so looking for improvements (especially with REST and JSON). Would like capability to create SOBA's (Service Oriented Business Applications) in a combined APEX + BPEL tool.

Architecture tooling: Need a tool that competes with IBM System Architect/Rational tools to tie in diagrams, UML, architecture assets. These are a big part of the SOA landscape. Enterprise Architects, SOA Architects, Business Architects use these type of tools and standardize their architecture team on them. It helps provide the overall infrastructure for architecture team.

Sharepoint competitive tool: Would like to see Oracle release a Knowledge Management tool that allows for improved collaboration and asset sharing.

Cloud and SaaS Enablement: Sun has made some inroads into Cloud, but really haven't heard too much on how Oracle wants to move in that direction. Hopefully, the acquisition will open this up as a new Oracle market.

Compared to ERP, SOA got Unlucky

Flash back to the 1990's. Organizations were spending triple-digit millions of dollars to implement ERP systems. I worked for a Big 5 consultancy at that time, and we were closing weekly $50M deals for being the system integrator on ERP implementations. Times were great! The promise of a new era was there. The cure for "IT cancer" was solved through ERP, right? Not exactly, but CIO's were spending massive amounts of dollars and willing to wait 2-3 years to see slow-moving ERP implementation projects finally hit the Production-ready datacenters. Servers were ordered in the hundreds and rolled out without a second guess. And what were the results of the ERP-era? At that time, that didn't matter too much, as everyone was convinced this was all we needed.

I certainly can't argue that ERP systems were or are a bad decision-- I think ERP is a necessary evil that most organizations need to have, simply to get the benefits of the business rules, data collection, server-based and distributed computing, and consolidation of capabilities. But, ERP certainly didn't solve the promises of being the entire IT Universe (maybe, just the Master of the Universe?). No one can argue that an IT dept only needs an ERP system, hence the need for SOA to help connect the entire IT portfolio. The challenge we face today, is the timing and new attitudes that are driving today's IT projects compared to those of the 1990's.

Flash forward to 2009. SOA projects are getting short leashes-- CIO's are asking for quick results and not willing to make large investments on SOA until they are very confident that the results will be there, quickly. If the results aren't near immediate, death to your SOA project-- SOA projects have been cancelled, and some analysts are claiming SOA is dead. So, why is this happening? Why didn't SOA get the $100M budget and the 2-3 year patience of CIO's from the last decade?

Before I hypthesize on the reasons for the IT spending shift, I did find it necessary to mention I have yet to meet a prospect or customer who diminshes the value of SOA-- there is universal agreement that it's something that could benefit business and IT alike. Whether you call it SOA, EA, EAI, business architecture, webServices, process modeling, integration, legacy modernization, cloud-- we are all talking about the same thing and very rarely am I questioned on the value. However, there is a lot of nervousness, trepidation, and lack of funding to do SOA. How can this be?

Well, timing is everything. First, the role of CIO has changed. CIO's are under extreme pressure from the CEO and CFO to ensure rapid results. If SOA had gained traction during the mid-90's, today's issues would not have been a concern and everything would be happy in SOA-land and I wouldn't be writing this blog post. However, back then, we were too busy building today's silo's to worry about connectiong them. Also, the patience and funding has changed over the past 15 years. SOA got unlucky from that perspective. Very few organizations get the "big bang" funding to roll-out enterprise SOA. Sorry SOA, times have changed. There is also a fair amount of confusion and lack of education on SOA. I meet a lot of organzations who don't understand the underlying SOA, fundamentals, principles-- they know they want to connect systems, empower their LOB's, and automate business processes, but they are still confused about SOA. Your not going to invest in something you don't understand, so that is certainly a barrier to championing an SOA project.

So, SOA evangelists, Architects, sales reps, and ISV's we all have our work cut out for us-- our customers tell us they need SOA, but they don't want to spend big dollars. My advice: keep your chin up, keep spreading the gospel on the value of service orientation, and be content on doing small SOA projects rapidly. There is a pot of gold at the end of the rainbow, and if you can prove that SOA is legit and willing to take your initiative one bite at a time and tie ROI to each bite, there is no denying the fact that the SOA Journey will survive.

How to avoid an SOA Virus: Focus on the data. Part 1

Data is the core of SOA. Without data, the SOA world does not go around. Why do I say this? If you boil SOA down to its lowest common denominator, we are simply attempting to do something that has been the goal of information systems (if not the goal of mankind and human survival) since the dawn of the computer:

(1) Share and move data amongst systems
(2) Transform data into information so it is usable for decision making
(3) Provide better visibility into information throughout the organization

Nothing fancy here, as an organization’s business objectives are dependent on high quality data and anything less will diminish these objectives. Bad data translates to bad results, and leads to the idiom we hear so often in IT meetings: Garbage in, garbage out.

Organizations always need to ensure their data is of the utmost quality to be successful, and if that is not the case, what’s the value of implementing big SOA components? Could we be looking at more lipstick on the pig? What happens if you architect all these big SOA capabilities from the SOA Ecosystem, only to find out the data that is passing through them is bad to begin with? Will your BAM, ESB, or BPM solution fix bad data? Will your BAM, ESB, and BPM solutions provide visibility on when and where the data went bad? Will they help you to find the source of the problem? Unfortunately, big SOA products do not have these root cause analysis capabilities.

Think about this analogy. You are a company who wants to manufacture a product. You invest heavily in a state-of-the art manufacturing plant with large-scale infrastructure to turn out products. After a lengthy implementation cycle to get your plant ready, your infrastructure and architecture is finally complete and in place. Now your plant is ready to start running and turning raw material into finished goods that will be consumed in the marketplace. After a few weeks of processing and shipping goods into the marketplace, you are noticing consumers no longer desire your product. Demand plummets and customer feedback is that your product is of poor quality. After a long and intensive investigation, you discover that the raw materials used in producing your product, were of poor quality to begin with. Due to the dependency on the material, your product was directly impacted and never stood a chance of being successful. Ultimately, because the input was not up to standard, your product and company failed.

This same analogy can be applied to SOA and why CIO’s are hesitant to invest in large-scale SOA projects-- one of the main reasons large-scale SOA efforts fail—a company will build an industrial strength SOA infrastructure, but the data passing through the SOA layers was never of quality to begin with, and hence the information output from the SOA architecture is of poor quality, leading to consumer abandonment. SOA is dependent on the data it receives in the same sense a manufacturer is dependent on the raw materials it receives. An SOA infrastructure is a large investment, just like a manufacturing plant is a large investment. Just like the manufacturer’s goods took a hit in the marketplace, SOA will take the corporate blame when poor data is passed down the line (when the real culprit was the source systems providing the bad data). And most importantly, an SOA initiative will fail, just like a manufacturer will fail, if careful attention is not paid to preemptively analyzing the input before it is processed.

Another way to look at this, is big SOA is potential channel for an enterprise virus. Think about this: when big SOA capabilities provide or consume the bad data, they are helping to exponentially spread bad information across the enterprise because of the number of systems, processes, and people SOA provides for and touches. The bad information gets exasperated across business units, trading partners, and throughout the corporate landscape, leading to misinformed and incorrect decisions. Ultimately, funds and resources are wasted. This is where the SOA practitioners need to be careful so that the value of SOA re-usability does not actually work against them in a viral fashion.

Part 2 of this topic will cover how to avoid the pitfalls of an SOA Virus and ensure data works toward your SOA benefit.

Big SOA is Dead, Little SOA is Thriving

I somewhat agree with Anne Thomas Manes SOA is Dead, but I think it is more appropriate to claim: "Big SOA is Dead; Little SOA is Thriving".

What do I mean by this?

I think BPM, BAM, and ESB initiatives (i.e. Big SOA) are suffering from being large, complex, and somewhat bloated efforts to gaining SOA momentum. Customers want rapid results. They want quick services, quick ROI, they want [sic] SOA Today. That translates to lightweight SOA that is simple and digestible without having to buy or learn an entire software suite or vendor tool platform just to get your first 50 services out the door. This is Little SOA. Tools that can rapidly create services in minutes, rather than months.

Now before I get Savvion, Lombardi, and other BPM player lining up to slice me to virtual pieces, I will precursor by saying BPM, BAM, and ESB are still necessary in an SOA Architecture...just not necessary to start and progress your first chapter of your SOA Journey. Take any of the 1,000 SOA maturity models out there, and the first step is to create services, right? So, why invest in Big SOA to start? The capabilities of these Big SOA tools like BPM, BAM, and ESB can be delayed for 6-9 months, possibly even a good year until your business requires these efforts. How does that sound to your 2009 budget! Finally, some good news! Application-to-Application and Composite Application consumption of business services can thrive without these Big SOA tools; however, there is a caveat that Business Process Automation (BPM, Workflow, BAM) will have to wait-- sorry, Little SOA isn't perfect!

As you can see, my proclomation favors a bottoms-up or middle-out strategy in developing services, as opposed to Top-Down and modeling all your business processes before defining your servcies. If you had asked me 6 months ago, I would have told you Bottoms up is bad and that all your business processes need to be defined before you start mapping activities to services. And, Top-Down is certainly a viable academic approach. It's just not practical. Especially in today's economic climate. Think about how time consuming BPM is, and most CIO's will not buy-into this 1-2 year Top-Down BPM investment. Most CIO's only last a couple of years at each job stop , so they don't want to do BPM on their dime. How can you blame them when it takes an large time and monetary investment to model As-Is and To-Be processes, not to mention standaridzation, education, and maintenance? Although Big SOA maybe the more academically powerful approach, my customers just don't have the patience for Big SOA. They want [sic] SOA Today!

To summarize, buying an SOA software stack for $500kk-$1M+ is not starting small! Organizations can not afford these Big SOA products anyhow in 2009. Gartner and IDC will certainly agree that you don't start with an ESB in your SOA Journey, so you can buy your SOA stack when you are more knee deep into your SOA project and the capabilities are required. (Hey, I'm just echoing analyst sentiment!) However, you do need something to get your services out the door and for the beginners to get off the SOA sidelines. Think long and hard by making investments into Little SOA products to start, and then you can realize the value of being simple, rapid, agile, and most importantly AFFORDABLE.

Who am I?

This blog was originally started in August 2008, and this post is a re-post of the first content I published on soa-today.blogspot.com back in August 2008, the date when this blog was orginally invented. Please keep in mind that the views, opinions, and recomendations of this blog are soley those of Jordan Braunstein. This blog is not associated with any company and is the personal blog of Jordan Braunstein. User comments on this blog and content will only be addressed during non-business hours, so not to interfere with my daily work tasks -- thanks for your understanding!

Finally! Finally off my tuchus and starting a blog. As the saying goes, long time listener, first time caller. My blog will be centered around an industry that I have consulted in for many years, Service Oriented Architecture (SOA). This term SOA means so many things to so many people, so I will cover all the expansive definitions and applications, but my main goal is to make SOA simple, digestable, and easy to implement! An IT paradigm that is easy?...holy cow!

Through my trials and tribulations, I've encountered enough organizations frustrated with SOA to believe I need to tell them (and the greater Universe as well) how SOA can be easy (so easy a caveman can do it!). You just have to do it the right way, and many organizations don't start the right way...but that's ok...I know how to fix things that have gone down the wrong path, and it doesn't involve taking a magic pill....but sometimes they do call me the Wolf (Pulp Fiction).

So, this blog will be an information source for how to make SOA simple (since I am a practitioner in reductionism!).

For you curious minds, here is my background, and credentials:

I've been in the SOA, EAI, B2Bi, Legacy Modernization space for just over 11 years (time flys when your having fun...). I've worked with roughly 100 customers and partners advising and implementing integration implementations that have positive business results. I've seen the trends, buzz, and flavors the day come and go. Ultimately, I know how to get business excited about IT solutions and for good reason-- IT does matter! It is an enabler!

I ventured into SOA (EAI back in 1998) as the first East Coast consultant for Active Software (think Brokers and adapters), worked a # of years for webMethods as a field Architect (think EAI, B2Bi, Mainframe integration) after Active Software was acquired by webMethods; I free-lanced as an SOA Architect for a number of years helping customers with building sound architecture and governance; I started BearingPoint Public Service's SOA practice (focus on Federal clients, but some State and Higher Ed too), and now I am working with customers to ensure sound SOA, EA, and BPM practices.

I look forward to collaberating with others, and feel free to contact me with any comments, questions, concerns, or complaints.


Thanks for reading and enjoy!