Wednesday, December 23, 2009
Looking back on 2009 - What development in SOA am I most thankful for?
* Originally posted in the ebizQ SOA Forum on December 23, 2009
Monday, November 23, 2009
Hot off the Press - Avoiding the Storms: Why We Need Cloud Governance
Yes, today's forecast is scattered clouds. Scattered clouds imply a nice day with mostly sunny skies and a few scattered showers. But don't let today's sunny skies lull you to a complacent afternoon siesta. An unfettered increase in "scattered clouds" could mean that today's sunny skies are just the calm before the raging storms arrive.
Without proper planning and oversight (i.e. governance), cloud computing will inevitably have the same story as SOA. My latest feature, Avoiding the Storms: Why We Need Cloud Governance, explores this train of thought.
Thursday, November 19, 2009
Is SOA Everywhere?
Joe McKendrick explains his question as "while some viewed SOA as failed or dead, a different reality may have taken root. That is, everything about IT - developing, integrating, embedding, and modeling - is now done in a service-oriented way, or with service orientation as the goal. Have SOA principles become so ubiquitous they have simply melded into the background?"
As I pondered over the answer, I was reminded of the story of a very talented painter named Zeuxis, who could paint amazingly life-like pictures. Once he painted a painting of a boy carrying a basket of ripe red cherries. When he hung this painting outside his door, some birds flew down and tried to carry the cherries away. "Ah! this picture is a failure," he said. "For if the boy had been as well painted as the cherries, the birds would have been afraid to come near him."
The moral of the story is that if an SOA is done correctly, it should meld into the background rather than sticking out like a sore thumb. Conversely, good SOAs are hard to find not because they don't exist but because they have become part of the fabric of the enterprise.
* Originally posted on the ebizQ SOA Forum on 11/19/2009
Thursday, November 5, 2009
Does cloud computing need malpractice safeguards?
I respond with a simple question of my own:
The fact is that many of the existing regulations already apply to clouds. For example, information security on government clouds is still subject to the Federal Information Security Management Act (FISMA), although a few enhancements are being discussed to make the act more amenable (i.e. less bureaucratic) for clouds. Similarly, all of the data privacy (national and transborder) laws still apply to a cloud environment. Thus, IMHO, most of the legal issues surrounding clouds may already be addressed within the context of the existing legal framework reinforced by contractually enforceable SLAs. An evolving body of "case law" may also help address some of the "grey" issues that arise as cloud use becomes more pervasive.
At the same time, I don't think we can completely rule out the possibility of a few new and very cloud-specific regulations, especially if they help alleviate public concern and increase speed of adoption.
Monday, October 26, 2009
Hot off the Press - Eight Myths of Cloud Computing
As Taylor Rickard, chief technology officer of G&B Solutions, so eloquently puts it, “Ask 25 people what cloud computing means and you are likely to get 30 different definitions.” With so much disinformation out there, is it any wonder that there are so many myths associated with clouds? My latest article dispels eight of the most common myths.
Read the complete article here
Friday, October 23, 2009
Hot off the Press - Open Government - Five Key IT Issues
We have barely scratched the surface regarding social media use in the pursuit of an Open Government. The root problem is an "impendence mismatch" between the federal operating environment and the technology -- namely, a federal environment that is still very 20th century and a technology that is very 21st century.
Interested?
Read my latest article Open Government - Five Key IT Issues.
Tuesday, October 13, 2009
Hot off the Press - The Cloud SOA Ecosystem
The union of SOA and the cloud goes beyond a simple convergence – it actually represents an ecosystem. Read my feature article on ebizQ titled The Cloud SOA ecosystem to find out why.
Thursday, October 8, 2009
Can Cloud Defend Against DDoS Attacks?
The blog entry makes an intersting observation claiming that:
"...cloud computing services, such as Google's App Engine and Amazon's Elastic Compute Cloud, or EC2, provide flexible hosting resources that can grow to accommodate a surge in demand. Imagine if the agencies that were affected by the [DDoS] attacks had been sitting in the cloud when the malicious traffic started rolling in. The ability to disrupt agency websites becomes a function of how much capacity Google and Amazon have to support the requests. These providers likely have plenty of bandwidth to sustain the attack and provide service with little to no service disruption.
Here's my problem:
Claiming that "cloud computing services, such as Google's App Engine and Amazon's Elastic Compute Cloud, or EC2, have plenty of bandwidth to sustain a DDoS attack" is akin to arguing that "you can tolerate the cold winter better by becoming fatter."
Is the fact that we have more scalabilty even relevant in a discussion about security?
Friday, October 2, 2009
What are Enterprise IT Geeks Obsessed With Today?
"What are Enterprise IT Geeks Obsessed With Today?"
LOL... Now how could I possibly answer this question? :)
However, if in some parallel universe, I were an Enterprise IT Geek then I would be obsessed with:
A. Justifying all of the acronyms we have today,
B. Coming up with new and improved reasons as to why all the above are still not enough to create an "enterprise" solution on time and on budget, and
C. A program that generates new, sensible sounding acronyms that I would say are essential to getting what I stated was missing in B (above)
This would be an iterative process in its entirety and in between stages and its implementation would beg, borrow, and steal from the best-of-breed Agile processes (XP, Scrum, etc.).
But then, as I stated before, I'm not a Geek, so what would I know? :)
Enough said... now it's time to get back to work!
Thursday, September 24, 2009
My SOA Elevator Speech
"You're the CIO of a Fortune 500 company and you step into an elevator with your CEO. He asks why we should approve your seven figure SOA budget request. So what's your "elevator pitch" for SOA? Make it short and to the point – the elevator is already rising fast."
So, what would my answer be?
"SOA is the centerpiece of our IT strategy in direct alignment with the board of director mandated enterprise-level risk management initiative that ensures IT continuity, resilience, compliance with regulatory requirements such as SOX, asset protection, and minimization of negative financial exposure."
BTW, I timed my response to 25 seconds :).
* Originally posted on the ebizQ SOA Forum on September 24, 2009
Monday, September 21, 2009
The Economic Downturn and the IT Diet...
Once upon a time there was a very obese person... sort of a "super size me" kind of guy. One day, he got a terrible scare with his first heart attack at age 34. Fortunately, he survived, and is now a much fitter and leaner individual at 35 years age. Is that a good thing?
Of course it is!
Well, to play devil's advocate, it would not have been so good if he had just starved himself. But this individual joined a gym, started a regular exercise program that included both aerobic and anerobic exercises, and went on a nutrition-balance diet. In a similar "vein", a "balanced and strategic" technology cost cutting initiative is a good thing too since most organizations were long due for such an effort having become "obese" with the long period of economic prosperity.
Finally, to bring our story full circle, just as a balanced diet and regular exercise is good for anyone to maintain good personal health, technology cost cutting initiatives should be ongoing and continuous as well to maintain good IT health.
* Originally posted in the ebizQ Cloud Computing Forum on September 21, 2009
Friday, September 18, 2009
Is Service Reuse Overrated as a Value Proposition for SOA?
When SOA first started climbing up the hype cycle, it was pushed to developers as a way to increase the "reusability" of their code by making everything into a service. This created at least two problems with the first being a massive service proliferation as developers eager to jump on the SOA bandwagon made everything into a service, which in turn led to poorly performing architectures (not SOA's fault) and huge issues around service management and governance. The second problem was that upper management and the mainstream media also started "drinking the reuse Kool-Aid" served by the bottom ranks.
The fact is that reuse is only a by-product of SOA. Adopting SOA for reuse is like saying that you're working out to sweat (instead of for losing weight, building muscle, or improving overall health). In fact, I would contend that the re-use provided by SOA is only marginally better than what we've had in previous architecture generations. We've gone through libraries and modules in procedure-oriented architectures, objects in OO architectures, components in component-based architectures, and now servces in SOA. A key issue around reuse is not the technology but the identification, segregation, and granularity of "reuse" items - none of which are dependent on what architecture style you are using. The real value of SOA is as a building block of the larger enterprise-level strategy of aligning IT with the business to ensure that IT value is justified, IT supports the business objectives, and IT has an equivalent level of agility to adapt with changing business needs. In some cases, SOA even becomes the catalyst that spurs the IT alignment to business objectives.
In a nutshell, SOA is about strategic IT alignment with business goals and objectives. Service reuse is only an operational - not even tactical - outcome of SOA. A corollary to the discussion is that many bottom-up adoptions of SOA start with lofty reuse objectives and either quickly become disillusioned or fail to demonstrate adequate value to the rest of the organization because their original reuse goals are far from being met. That is why SOA has the best chance of success with a top-down adoption with the long term sight on strategic alignment objectives rather than operational reuse objectives.
Originally posted on the ebizQ SOA Forum on September 18, 2009
Thursday, September 10, 2009
Do You Think the Pervasive Use of Cloud Computing Will Expand or Contract the Use of SOA?
Most SOA and Cloud practitioners have probably wondered about this very same thing. I definitely have asked myself this question - albeit in different forms - many times over the past couple of years. A while back (2007) I had written an article in ebizQ titled Leveraging Synergies: RTI and SOA Unite in which I talk about using RTI (think an internal, private cloud) and SOA together for two main reasons:
- They share similar objectives
Both RTI and SOA seek to maximize ROI albeit at different layers of the technology stack; RTI at the infrastructure (hardware) layer and SOA at the business application (software) layer. - They complement each other
Using one concept (SOA or RTI) without the other leads to an impedance mismatch between the infrastructure and application layers resulting in suboptimal benefits realization.
The same logic applies to application architecture targeted to cloud environments. In fact, you could say that the cloud is the "A" in SOA :). With clouds, SOA has a winning partnership such that if there were ever any doubts about the long-term strategic benefits of SOA, clouds help alleviate most if not all of them.
Originally posted in the ebizQ SOA Forum on September 10, 2009.
Wednesday, September 9, 2009
Are Private Clouds an Abomination?
A "private" cloud is just as much of a cloud as any other.
The typical private cloud is a cloud in which the cloud infrastructure is operated solely for an organization. It may be managed by the organization or a third party and may exist on premise or off premise. Since all consumers of the private cloud are “trusted” (i.e. within the organization’s legal/contractual umbrella such as employees, contractors, & business partners), multi-tenancy, which is a big deal in the public clouds, becomes less of an issue.
However, a private cloud still satisfies the essential characteristics of what a cloud is.
NIST, for example, defines five essential characteristics of a cloud: On-demand self-service, Broad Network access, Resource Pooling, Rapid Elasticity, and Measured Service. Now consider the Cloud Security Alliance, which also defines the cloud in terms of five principal characteristics: Abstraction of Infrastructure, Resource Democratization, Services Oriented Architecture, Elasticity/Dynamism of Resources, and Utility model of Consumption & Allocation. Every other authoritative definition that I have come across defines the cloud in the context of similar essential characteristics. There is no reference to ownership of resources, sharing the cloud between organizations, competitors, across national or international boundaries, or the use of the public Internet as the backbone. It is because they are not essential characteristics of a cloud.
So, no, a “private” cloud is not an oxymoron. Would "public" cloud providers like us to believe so? Sure, but the fact is a private cloud is a necessity at times due to organizational maturity/capability/culture constraints, regulatory requirements, or SLAs that cannot otherwise be met.
Originally posted in the ebizQ Web 2.0 Forum on Septmeber 8, 2009.
Wednesday, August 19, 2009
Is Cloud All Hype?
Cloud Computing is definitely not just all hype. Are there unreal expectations related to the "cloud"? Sure, there are, which is not unlike with any other "star" technology such as SOA. The "tending to infinity" number of definitions of a cloud is not helping; nor are all the vendors scrambling to reposition their products and services as being what "cloud" is all about. But, when you cut through whatever hype there is and dispel the myths you end up with a business and technology model that is rooted in best practices and a solid track record. The underpinnings of cloud are not new. Virtualization, SOA, Utility and Grid Computing, and the various "-as-a-platforms" have been around in one form or another for a while; each with success stories of its own. Keeping that in mind, "cloud" is simply the next stage in the continuing maturity evolution of our use of technology to achieve business goals in the most efficient and cost effective manner. Cloud Computing is definitely real and is here to stay for the long haul.
* Originally posted in the ebizQ Cloud Computing Forum on August 19, 2009.
Tuesday, July 21, 2009
Where Do you Think Web 2.0 Applications Are Going Next?
That's what I've been researching these past few days. The answer to me seems to be a combination of what is referred to as Web 3.0 and Web 3D.
Web 3.0 is taking the current Web 2.0, which focusses on building relationships and social networking, into the next phase of converting the "relationship" data into knowledge that can then support "context sensitive" and "semantics based" searching. In the ideal Web 3.0 world, the browser would act like a personal assistant. As you search the Web, the browser learns what you are interested in. So, the more you browse, the more it learns about you until eventually it can confidently answer questions such as "where should I go for lunch?" or "what movie should I watch?".
Web 3D combines virtual reality elements with the persistent online worlds of massively multiplayer online role-playing games (MMORPGs) transforming the Web into a digital landscape that incorporates the illusion of depth. In a Web 3D world you would navigate the Web through a digital representation of yourself called an avatar.
Ultimately, I think we'll see elements of both, neither 100%, in the future of Web 2.0. Also, I strongly feel that the Web will continue to merge with other forms of entertainment until all distinction between media are lost to the point that radio programs, television shows, and movies all rely on the Web as a delivery system.
* Originally posted in the ebizQ SOA Forum on July 21, 2009.
Thursday, July 16, 2009
Do You Believe that the Quality of SOA Related Projects Will Improve or Decline in the Future?
Find out how industry experts are responding to my question on the ebizQ SOA forum...
Thursday, July 9, 2009
How Will SOA Vendors Adapt to the Emerging Cloud Paradigm?
SOA alongwith other technologies such as Virtualization, Grid Computing, Broadband Networks, Open Source Software, Web 2.0, etc. form the foundation for Cloud Computing. We all know how hot Cloud Computing is being in the very early stages of its hype cycle. So it stands to reason that SOA vendors will very likely jump on the Cloud Computing bandwagon in order to marginalize any discussion about the relevance of SOA. After all, as they would say, how can SOA be dead if it forms a foundation for the "new" best thing since sliced bread - Cloud Computing?
* Originally posted in the ebizQ SOA Forum on July 9, 2009.
Tuesday, June 30, 2009
Are Social Networks Working for Businesses?
Assessing the business value of Web 2.0 is similar to assessing the business value of an analytical (OLAP) database in that the real value of an OLAP is not in the database itself but rather in the "knowledge" gained by analyzing the "patterns" of data within the database. Web 2.0 is the philosophy and associated web-based tools (such as twitter, linkedin, facebook, myspace, orkut, etc.) of creating a more "personalized", "humanizing" web experience. Just as in the case of an OLAP database, the real business value of Web 2.0 is neither in the philosophy nor in the toolset but in the "relationships" and personal information captured about the users that was previously unavailable in Web 1.0. Companies across the world are burning midnight oil trying to decode all of this new data about online relationships hoping to strike gold with profitable insights. Companies such as Facebook have grandiose visions about changing the way people interact over the web and even displacing Google as the "search engine" of choice. Decoding these online relationships in the sea of data within the depths of Web 2.0 could be just the keys needed to unlock unheard of riches!
* Originally posted on ebizQ Forum on June 30, 2009
Friday, June 26, 2009
Is There Such a Thing as "SOA-in-a-Box"?
- Provide a comprehensive methodology from inception to retirement. The methodology should describe the method for defining an SOA in terms of a set of building blocks and
show how the building blocks fit together. - Provide a common vocabulary
- Include a list of recommended standards
- Provide guidance on implementation patterns
- Provide a comprehensive set of "starter" models, templates, samples, best practices, and project management related artifacts.
- Contain a prescriptive recommendation of a set of tools and compliant products that can be used to implement the building blocks.
* Originally posted on ebizQ's SOA Forum on June 26, 2009
Sunday, June 21, 2009
Is SOA Being Employed as a Tool for Streamlining or Cutting Budgets, or is SOA a Victim of the Budget Knife Itself?
Budget decisions are made based on strategic, operational, and tactical objectives - in that order of preference. SOA really should not play a role in that decision as it is the means to an end. That is, SOA is the means to achieving IT alignment with the business with the end goal being becoming more "agile" in meeting the business objectives. So, the budget decision might be to marginalize the priority of a certain set of business objectives, which in turn might nix an SOA initiative. Contrarily, as other business objectives gain priority, SOA should be a consideration in the implementation of those objectives. So, the nutshell is that whether or not SOA gets used as a tool to stream operations or gets the knife itself is really a "side effect" of business level decisions related to long-term goals and objectives.
* Originally posted on ebizQ's SOA Forum on June 21, 2009
Saturday, June 13, 2009
Hot off the Press... Silver Line Your Cloud with 6 Strategic Considerations
Read more...
Silver Line Your Cloud with 6 Strategic Considerations
Friday, June 5, 2009
What's Killing BI in the Enterprise?
* Originally posted on ebizQ's SaaS Forum on June 5, 2009
Monday, June 1, 2009
Should SaaS Vendors Offer On-Premise Options?
* Originally posted on ebizQ's SaaS Forum on June 1, 2009
Sunday, May 31, 2009
Do You Believe SOA Related Projects Will Increase or Decrease in the Future?
A related question though was anwered previously on the ebizQ SOA forum related to the Biggest SOA inhibitors. So, while I am confident that the number of SOA projects will increase in the future, the rate at which that will occur depends on how well these inhibitors will be overcome.
Another question that comes to mind relates to the never ending debate between "Quantity" and "Quality". While numbers are important, they don't tell the whole story. Are we better off if the number of SOA projects goes up while the success rate (aka quality) does not or gets worse? Yes, thinking about quantity is important, especially as one embarks on new initiatives and wants to ensure that they will not fall behind the times even before their initiative is over but remember that any discussion about quantity must be balanced with a corresponding discussion on quality.
So, I end this post with the question:
Do You Believe that the Quality of SOA Related Projects Will Increase or Decrease in the Future?
* Originally posted on ebizQ's SOA Forum on May 31, 2009
Wednesday, May 20, 2009
What Do You Believe is the Biggest Inhibitor Today to SOA Adoption?
Here are six key inhibitors that I have experienced over the years:
- Unrealistic or misunderstood goals and expections— As with any substantial project, level-setting expections and gaining a common understanding of the goals/benefits amongst the stakeholders is key to the success of an SOA implementation.
- Tactical instead of Strategic Approach— SOA is best implemented top-down with a strategic view of the business processes and functions to be exposed as services. Bottom-up implementations too often tend to be overly focused on technoology rather than the business
- Not putting your money where your mouth is— Let's be realistic: The best intentions won't go too far without money being spent. SOA requires an investment in your resources (people, tools, and technology) to be successful. There is no free lunch in life.
- Poor Governance— Poor or complete lack of governance can lead to service proliferation, which can ultimately lead to more severe problems with data integrity, meeting SLAs, and privacy/security breaches.
- Organizational Power Struggles— In an SOA the focus moves away from individual applications and data stores to more business-oriented services that may cross business unit and organizational boundaries. This breakdown in application and data barriers may cause heartburn to the owners of those applications and data, who may see this as a challenge to their power see advantage in hindering the SOA implementation.
- Fear and Ignorance— SOA is surrounded by many misconceptions regarding exactly what it is and what it takes. Too much has been said about all the technical details/variations leading to the misguided belief that any SOA implementation must have "all that" technology and complexity. Ignorance breeds fear, which then becomes a major inhibitor.
* Originally posted on ebizQ's SOA Forum on May 20, 2009
Thursday, May 14, 2009
Hot off the Press... What's in it for IT?
Follow my journey to seek the answer in my latest article on "What Obama's Stimulus Plan means for IT" in the Gameplan section (page 10) of the May 2009 issue of Baseline magazine.
Tuesday, May 12, 2009
What Impact is Web 2.0 Having on Marketing?
* Originally posted on ebizQ's SOA Forum on May 12, 2009
Thursday, May 7, 2009
How Can Small to Medium Sized Enterprises Benefit from SOA?
The primary benefit of an SOA to small and medium sized businesses (SMB) is exactly the same as it is for a large sized company - business and IT alignment. In other words, the value potential of an SOA, as an architectural style, is not tied to the size of a company. Having said that, the next question that might come to mind is "Are SMBs ready for an SOA?" They absolutely should be ready and my guess is that if they think they are not then it's probably because they have been misguided as to what SOA really is. SOA is not about Web Services and the hundreds of associated WS-* standards; nor is it about deploying a mandatory Enterprise Service Bus and encapsulating every single business interaction as a BPEL workflow. SOA is not about technology; it's about optimizing your business by aligning your IT capabilities with your current and anticipated business needs. Once you abstract all that technology out and think about SOA with your business hat on, you'll quickly see that SMBs have as much to gain with SOA as any other sized company.
* Originally posted on ebizQ's SOA Forum on May 7, 2009.
Thursday, April 30, 2009
Hot off the Press - TOGAF 9 Applied: One Iteration at a Time
Check it out at http://www.ebizq.net/topics/soa/features/11247.html
Thursday, April 23, 2009
What's the Best Way to Measure SOA Success?
Tuesday, April 14, 2009
Hot off the Press - Enterprise SOA: Five steps to the next frontier
To find out more check out my latest article on creating an enterprise class SOA implementation, which just got published today in IT World.
http://www.itworld.com/soa/66397/enterprise-soa-five-steps-next-frontier.
Wednesday, April 8, 2009
Cloud Computing - Who should define the standards?
Wednesday, April 1, 2009
Is "Guerrilla SOA" a Realistic Option When the CEO Doesn't Approve Your Budget?
Antipattern #3: Service Fiefdoms
This is the corollary of antipattern #2 (The "Big Bang" Approach). Here, instead of taking an enterprise view to the SOA transformation, each vertical silo within the company goes off on their own and recreates their applications as services within an SOA. In this case, there is the potential for a lot of duplication of effort due to the lack of an enterprise view. Furthermore, this fragmented approach to the SOA transformation often fails to create reusable organizational assets, which is one of the key benefits of undergoing the transformation that leads to higher organizational efficiency and improved cost effectiveness.
Antipattern #4: Technophilia
This is an antipattern that occurs when the SOA initiative is led bottom-up instead of top-down i.e. when the "techies" are leading the initiative. Instead of the SOA initiative starting with the study of the processes that drive the business, the technology that will power the SOA becomes the apex of the effort. Instead of representing the business, the drivers of the SOA initiative get too wrapped up in technology specifics such XML, Web Services, determining which versions of the various technology standards to use, deciding how much BPEL will be needed, etc. Ultimately, such an SOA initiative does not yield the intended business benefits of creating reusable organizational assets.
The bottom line is that several years of experience has shown that for an SOA initiative to truly achieve its objectives it has to be a top-down effort; both organizationally and architecturally.
Tuesday, March 31, 2009
Does BI Go Together With SOA, or Should They be Considered Separate Projects?
As we already know, SOA is an architectural style that strives for business and IT alignment. SOA by itself is an open loop process because it achieves this alignment based only on the current business state and lacks the feedback mechanism to constantly ensure and optimize this alignment once it has been achieved. That is where BI fits in. BI is the broad category of applications and technologies that gather, store, analyze, and provide access to data aimed at helping the enterprise make better business decisions. These “better” decisions are what “close” the open loop SOA implementation by providing the feedback to ensure the continuous alignment between the business and IT. Click here to see the same concept pictorially.
So, although SOA and BI are fundamentally different, they can be very effective together since they both ultimately strive for business process efficiency, albeit in their own way. Now whether they are implemented together in the same program, as separate projects, or as subprojects of one project is purely an implementation decision that each organization must make for itself based on its individual capabilities.
Thursday, March 19, 2009
Do You Think IBM Is Really Going to Buy Sun Microsystems?
1. Technology related
Each company has a strong suite of products (Sun with SPARC, Solaris, Java, etc. and IBM with System z, AIX, WebSphere, etc.) with a strong following and customer base. These products are different enough to present serious challenges in creating a unified, consistent technology platform in a combined company.
2. Culture related
By far the biggest problem in the merger of two huge companies is going to be integrating the organizations, people, and processes. Ultimately, a dysfunctional culture in the resulting company might outweigh any potential benefits from synergies.
Personally, I always cringe when competition is reduced by M&A. We're seeing what's going on with the banks becoming too big to fail while paradoxically being too big to manage as well. Would IBM + Sun equate to the same?
Monday, March 16, 2009
Does SOA Increase Security Risks?
- The first reason is what I call "SOA Security Proximate Cause Syndrome". Proximate cause is a legal term that allows one to link the effect of one action as the cause of another action. Although, there is no written rule that states that SOA systems must be distributed, the fact remains that SOA is the preferred architectural style for complex systems and complex systems tend to be distributed. Distributed systems in turn tend to have a higher "surface area". The more surface area of a system, the more vulnerable it becomes. Thus, the distributed nature of SOA systems becomes the proximate cause of their potential higher insecurity.
- The second reason is what I call the "SOA Security Paradox". An SOA is by its very nature designed to be highly flexible, extensible, and maintainable. Now, think about the classic principle of security “Security through Obscurity". There in lies the paradox -- a conflict between the inherent goal of SOA and the implication of this goal on security.
- The third reason is poor SOA governance. In the absence of strict governance (design and runtime) SOA systems tend to suffer from service proliferation similar to a virus spreading through its host. These unchecked services often open previously unthought-of of security loopholes. As an example, consider a service that is always called by a client on the extranet through an authentication service. A new "rogue" i.e. "ungoverned" service on the intranet calls this same service without the use of the authentication service. Now, consider what happens if this new "rogue" services is called by the extranet client. Oops! Did we just bypass the authentication service? This simplistic example plays out more often than one might think.
So, is an SOA system inherently insecure? In principle it shouldn't be but our experience in practice has proven otherwise.
* Originally posted on ebizQ Forum on March 11, 2009
KISS Your Web Services
WS-Confusion?
Client Side Data Validation: A False Sense of Security
There are many benefits of creating a web application. A few of them are:
- The ability to leverage existing communication infrastructure and protocols
- The ability to leverage existing client side software (browsers) thus reducing the total development time and related costs.
- Reduced client-side deployment costs. For most webapps the only software required by a client is a compliant browser.
That’s where data validation and a properly designed validation framework fit in. No, this is not a typo or misprint. Security details such as SSL, certificate management, firewalls, etc. are important, but provide only the icing on the cake. They don’t guarantee that the cake (i.e. your webapp) is baked well. What I mean is that while these “details” may make it harder for a hacker to find holes in your webapp, they don’t seal the loopholes themselves. That is, they only delay the inevitable hacking of your application. Take SSL as an example. A common misconception is that SSL provides web application security. The fact is that it does not. SSL is used only to encrypt the data between the web browser and the web server, and thus prevents eavesdropping. SSL has no knowledge of your webapp and hence provides no security to it.
As a software consultant, I’ve had the opportunity to not only design and implement webapps but to assess/audit many webapps as well. I often encounter web pages within the application that are very sophisticated with lots of client side JavaScript that perform all kinds of checks on the data entered by the user. Even the HTML elements have data validation attributes such as MAXLENGTH. The HTML form is only submitted upon successful validation of all the data entered. The server side happily performs the business logic once it receives the posted form (request).
Do you see the problem here? The developers have made a big assumption of “control” here. They assume that all users of the webapp will be equally honest. They assume that all users will always access the webapp through the browser(s) that they (the developers) have tested upon. And so on. What they have forgotten is that it is very easy to simulate browser-like behavior through the command line using freely available tools. In fact, almost any “posted” form can be sent by typing in the appropriate URL in the browser window; although an easy way to prevent such “form posting” is to disable GET requests for these pages. But there is no way to prevent any one from simulating or even creating their own browser to hack into your system!
The underlying problem here is that the developers have failed to recognize the main difference between client side validation and server side validation. The main difference between the two is NOT where the validation is occurring such as on the client or on the server. The main difference is in the purpose behind the validation.
Client side validation is merely a convenience. It is performed to provide the user with quick feedback. It is performed to make the application appear responsive and give the illusion of a desktop application.
Server side validation, on the other hand, is a must for building a secure webapp. It is done to ensure that all data sent to the server from the client is valid data, no matter how the data was entered in on the client side.
Thus, only server side validation provides real application level security. Many developers fall into the trap of a false sense of security by performing all data validation only on the client side. Here are two examples to put things in perspective
Example 1
A typical “Logon” page has a textbox to enter a username and another textbox to enter a password. On the server side, one may encounter some code in the receiving servlet that constructs a SQL query of the form "SELECT * FROM SecurityTable WHERE username = '" + form.getParameter("username") + "' AND password = '" + form.getParameter("password") + "';" and execute it. If the query comes back with a row in the results then the user successfully logged in, otherwise not.
The first problem here is the way that the SQL is constructed, but let’s ignore that for this blog. What if the user types in a username such as “Alice’--“? Assuming that there is a user named “Alice” in SecurityTable, the user (or shall we call her “hacker”) successfully logs in. I’ll leave finding out why this happens as an exercise for you.
Some creative client side validation can prevent normal users from doing this from the browser. But what about the case where JavaScript is disabled on the client or for those advanced users (hackers) who can use another “browser like” program to send direct commands (HTTP POST and GET commands)? Server side validation is a must to prevent something like what was described above from happening and hence plugging a security hole in the webapp. SSL, firewalls, and the likes won’t help you here.
Example 2
A typical “User Registration” page for a public but limited access webapp includes several textboxes for user identification and authentication information such Name, SSN, Date of Birth, and other relatively uniquely known information. Once the user has proven her identity, she is issued a username and password to access the protected parts of the system. In special cases, the user may be prevented from directly registering and an “Administrative” user (i.e. the administrator) may have to register the user instead. The administrator uses the same registration page, but checkmarks a special checkbox on the page that tells the system (receiving servlet) to bypass all [special] checks and directly register the user. The JSP that renders the HTML page is smart enough only to include the checkbox if the user accessing the page is an administrator.
So far so good? Not unless there is some server side validation in the receiving servlet. The receiving servlet checks to see if the “bypass checks” parameter is present and if it is then it bypasses all special checks and registers the user. But it must also check to see if the logged in user is an administrator. Even though the JSP page did that when it rendered, the receiving servlet must perform the check again. In this case, the JSP check can actually be considered as part of the client side validation. It was merely done for convenience. After all, we don’t want to confuse regular users trying to register with the extra checkbox, since no matter what they select (checked or unchecked), it’s not going to make a difference. This is because regular users do not have the authority to bypass “authentication” checks. Furthermore, it would not be an impossible task for a hacker to figure out what the name of the checkbox was and manually issue a registration request with the checkbox name included in the request (with its value set to “checked” of course). Therefore the receiving servlet must check the identity of the logged on user (if there is a user logged on) and only allow an administrator to bypass special checks in the registration process.
Conclusion
Remember, client side validation is for convenience and server side validation is for security. You must always perform at least as much validation on the server as you perform on the client. All properly designed validation frameworks, such as the Struts Validation Framework, handle this for you. Feel free to leave me a comment and let me know your thoughts…
Model Driven Architecture - Hype Vs Reality
The Concept
The concept behind MDA is certainly not new and is quite simple in theory. In its most rudimentary form, it is the all too familiar code generation that has been offered by leading software modeling tools such as Rational Rose and the Together family of products. These tools allow you to model your system as a series of packages and classes (for Java) and then generate the skeletal code based off of these models. They also offer something called “round trip engineering” in which you can make changes to your code and import these into your models thus keeping your models in sync with your code. Although a very noble concept, I have rarely seen it fully implemented in real projects. Even if a project did implement “round trip engineering”, I would question the benefit provided for the cost of doing so.
MDA is more than code generation. It is a formalization of several concepts by the Object Management Group (OMG). The OMG is best known for its distributed object model specification called CORBA and the widely used modeling language called the Unified Modeling Language or UML.
The Lingo
At the very core of MDA is the concept of a model. A model is an abstraction of the end (or target) system. It serves as a prototype and a proof-of-concept. MDA defines two types of models. A Platform Independent Model (PIM) is one that describes the target system without any details about the specifics of the implementation platform. On the other hand, a Platform Specific Model (PSM) describes the target system on its intended platform, such as J2EE, .NET, CORBA, etc. The process of converting a PIM into a PSM is called transformation. A model (PIM or PSM) is written in a modeling language. The OMG does not restrict MDA to any particular language. However, the modeling language must be well defined, which means that it must be precise to allow interpretation by a computer. Therefore, a human language such as English is not an option (at least for the foreseeable future). An example of a good modeling language is (obviously) the UML.
Is it just Hype?
As I mentioned earlier, MDA is not a novel concept. We already talked about code generation, but database designers have been using a form of MDA for a long time. ErWin by Computer Associates is a CASE (Computer Aided Software Engineering) tool that provides MDA abilities to database designers and administrators. ErWin allows you to define your database design using a logical model. A logical database model is free from any database vendor specific details. In MDA terminology the logical model is a PIM. ErWin automates the process of converting the database agnostic logical model into a database specific (such as Oracle, SQL server, etc.) model. This database specific model is known as the physical model by database designers and as a PSM in MDA lingo. As I mentioned earlier, the process of converting a PIM into a PSM is called transformation. Finally, ErWin can be used to generate the SQL code (DDL) to create the database structure (tables, views, indexes, triggers, etc.) for the targeted database. Based on the definition of MDA and the capabilities offered by the tool, ErWin is an MDA tool. In this case the modeling language is the well defined E/R diagramming notation. So there is no doubt that MDA tools are possible. However, there are several hurdles to overcome before such tools become mainstream for general purpose software development, and especially for custom development.
Two such hurdles include:
Transformation Complexity Although designing a properly normalized database that meets the business needs and application performance demands is a non trivial task, the process of converting the database PIM into a PSM and the PSM into SQL is fairly mundane. Transforming complex class and interaction diagrams is a more involved and [possibly] artistic process with many possible alternatives, each one with its own set of pros and cons.
Language Expressiveness Once again, the simplistic E/R diagramming notation is sufficient for describing complex database diagrams mainly because the complexity is not in the diagram but rather in the design decisions and tradeoffs considered while creating the diagram. E/R notation is also universally accepted as the language used by database designers for data modeling. UML, on the other hand (even with 2.0) is very controversial in its ability to support complex software interactions and is often extended with custom stereotypes and notations by software architects and designers. Even though, MDA is not tied to UML, the reality is that UML is the lingua franca of MDA.
The RealityIn my opinion, MDA tools, even with their existing limitations, have a definite place in any architect’s toolbox. But then, everything can be taken to an extreme and the same applies to MDA, which is not without its associated hypes.
Here are the two most common ones that I encounter:
MDA brings Software Architecture to the masses Remember, MDA is a tool in an architect’s toolbox. It is not the toolbox itself and it is definitely not the architect. MDA does not eliminate the need for competent and experienced architects, designers, and coders on the team. As the saying goes “Not everyone with a hammer in their hand is a carpenter”.
MDA equals Software Architecture using pictures Is this really possible? Even in database modeling, where a level of MDA is already being used, how far does MDA take database architecture? Talk with any database designer or DBA and you will quickly realize that most of their work does not really revolve around using ErWin. The same applies to software architecture in general. It involves much more than drawing pictures. In fact, one could argue that it involves too much, which is why we are still struggling to come up with a universally accepted definition of software architecture.
So, my recommendation is to use the MDA tools for what they are… tools, and stay away from the hype. Maybe the next acronym to take root will be CDA or Command Driven Architecture (coined by yours truly). You basically tell (or command) the CDA tool that you want a robust, multi-tiered architecture for handling bank transactions and the tool creates it for you. And while it’s at it, maybe it will bake you some cookies as well. What do you think?
Sunday, March 15, 2009
Service Oriented Architecture - All that glitters is not gold
The phrase “Service-oriented Architecture” is probably by far one of the most used and abused buzzwords today. It is abused not because people don’t know what the term means, but because they are too generous in its application. Although this may seem paradoxical, as you’ll see in a moment, it’s really not so.
First, let’s define a service-oriented architecture or SOA as it’s commonly abbreviated and referred to in conversation and literature. In its simplest form, an SOA is any architecture that can, at least on a logical level, be decomposed into three categories of components: a service, a provider of the service, and a consumer of the service.
Here’s the catch: almost any software application with a basic level of object orientation can be described in such a way, even if the designer of the application had never heard of SOA! The problem with this definition is that it is too vague and does not imply any level of sophistication in the application [architecture]. So how do you know if an architecture that appears to be an SOA actually is an SOA?
Here are four litmus tests that I typically use:
- Does the architecture explicitly address how service consumers find service providers? This test focuses on loose coupling between service providers and consumers. Typically, this test is satisfied by an implementation of the Factory design pattern as described by the Gang of Four. One way of achieving this within the bounds of J2EE is registering service providers in a JNDI directory. A better way would be to implement the Service Locator pattern as described in Core J2EE patterns.
- Is each service provided by a provider explicitly bounded by an input and output contract? Once again, this test focuses on loose coupling. However, in this case, we are concerned about the coupling between the service and its provider and consumers. One way of satisfying this test within J2EE is to start each service implementation with two interface definitions: one interface encapsulates all the input parameters and the other one encapsulates the output. Web Services achieve this by using well-defined SOAP (XML) messages that specify the input and output, and by providing a well documented description of these using the Web Services Description Language (WSDL).
- Does the architecture explicitly address location and distribution transparency? Test #1 described above gets us part of the way there. However, this test focuses more on the quality of service (QoS) characteristics of the architecture, such as service availability, fault-tolerance, and the ability of achieving performance and load scalability through server load balancing, server farms, and distribution/deployment across multiple tiers.
- Are the services really just objects with another name? This test probes the architecture to see if it was actually designed as an SOA or simply labeled one for better marketing exposure. Services are not distributed objects. Objects are by definition stateful i.e. they encapsulate some state and provide methods to manipulate that state. Services, on the other hand are stateless. The input message has all the information that the service needs to perform its task and the output message has all the information the client needs back from the service. Thus, the interaction of a service consumer with a service is in the form of a single call rather than an orchestration of multiple calls as it is with a regular object.