The Tech Evangelist Leading IT Innovation One Blog Entry At A Time

10Dec/090

JP’s Topsy-Turvy 2009 IT Year in Review

This time of year is a great time to reflect upon the last 12 months and see what has occurred as well as discuss the impact of the events on this year and next.

The Big News

The big news in IT this year has to be Cloud Computing. Like the result of a Gremlin fed after midnight, Cloud Computing turned into the Stripe of the IT world. As pundits and vendors raced to gain mindshare as a means of priming the economy-dulled sales pipeline, IT buyers were caught trying to figure out, "is this the next great frontier, or am I going to look like an ass for recommending yet another useless acquisition?" Interestingly, cost is not the major driver behind these offerings, but instead access to compute resources on demand that don't require up-front capital expenditure. Now, they only have to figure out how to actually make it so their applications can work in the Enterprise, but shift to the Cloud for additional resources when needed. This should lead to some interesting Fail Blog stories next year since most companies barely have the right mix of resources to keep the lights on let alone actually architect (Webster actually lists this as a verb now, so if jiggy is a valid word in the dictionary, I guess I have to accept architect as a verb now) a distributed application capable of crossing compute boundaries. I will be watching a number of fronts, such as application virtualization and Open Virtualization Format (OVF) to see if these do anything to help with this issue.

iPhones were a big IT story this year. No, not the fact that businesses started using them as a platform, but that so many individuals actually opt to use their own iPhone paid for with their own dollars and often no reimbursement for their service plan instead of a nice corporate provided Blackberry. What's next, people paying for their own health plans?

Of course, we can't talk about big IT news without discussing the impact of social networking. It seems a day doesn't go by that I get an invite to join a new network site or share data about where I am or where I'm travelling. The election of 2008 illustrated how digitally connected we all are as multiple candidates leveraged social networking to connect with voters and disseminate their ideas. In 2009, we began to see that impact start to seriously hit at the doorstep of IT. Gone are the days where Facebook and Twitter are blocked by the firewall, it's now a requirement for businesses to extend their brand to these platforms. Employees are encouraged to Tweet and extend their networks via LinkedIn and collaboration has gone from buzzword to system requirement. I can't read Arabic, but I think Al-qaeda even has a fan page now on Facebook (yes, that is facetious). The point being that social networking has changed the way we think about communicating and doing business, however, we need to educate users of these applications of the potential risks. These applications are ripe grounds for delivery of malware and phishing attacks; even if you don't do anything other than update your profile and don't limit who has access to view. Think about what's in your Facebook profile: birthdate, pet's name, spouse's name, link to spouse, etc. I'm sure everyone reading this has used some aspect of this information as the means to access another computer system; and this is only one example of thousands. So, when social networking, remember, protection!

Finally, business intelligence has re-appeared on the scene. BI has been on and off the radar screens of business multiple times over the past twenty years. Perhaps it was the lack of technology to really deliver useful intelligence from the globs of growing and poorly-manicured data or the fact that when things go south business leaders look to the great Oracle (pun intended) to tell them how to run their business. Either way, BI is back in style along with men showing chest hair and platform shoes. It's like the 70's on acid. Unfortunately, I have some interesting news, unless you actually spend the millions necessary to get your data house in order, all the BI tools in the world are not going to provide you with an accurate picture of how your business is trending. Besides, you only need to look in your bank account to determine that. I do believe BI has some interesting applications when partnered with Complex Event Processing engines as a way to tell you that all hell has broken loose or is about to anyway.

The Ongoing Battles

Another year has passed and over that year the same 15-20 people have come out and debated the relative goodness/badness of SOA and BPM. Meanwhile, all the people actually developing solutions totally ignored what we had to say and many of them laughed heartily at us as they ran past us – straight into that brick wall. Hello? McFly??? Anyone in there??? We're not here debating among ourselves for the sheer joy of it (although, it is really fun to watch @aleksb6 get his knickers in twist as @bmichelson pushes his buttons). We're debating these issues because we realize there's hundreds of millions of dollars at stake for businesses who are laboring to keep their users satisfied and don't have the ability to fully understand all the nuances of developing large-scale distributed applications in a virtualized universe. So, why does some junior architect with three weeks of training from IBM or Zapthink believe they are capable of taking on a task that industry veterans cannot agree on a common approach for and be successful?

SOA is undefined, but it's not a technology and is not a platform for developing applications, yet you'd better figure a way to get it on your resume if you want a job in IT in the 21st century. BPM is a methodology and a science, but it is not a toolkit or application. Both of these initiatives require experienced IT veterans with an understanding of enterprise capabilities, mission-critical deployment, all the –ilities (high availability, scalability, reliability, transactionality, etc.) and a comprehensive understanding of the business in order to properly align technology choices and directions for a successful outcome. This is a big picture thinker with the ability to drive that picture back down into attainable goals. We call them Enterprise Architects, you call them …. only when you're already in trouble!

The Emerging Disruptors

And, now, the fun part of our little journey through IT-land, a look at what's going to be hot or bite you in the butt next year!

Numero uno on the list of emerging disruptors has to be cybersecurity. A quick search into salaries for IT security personnel quickly tells the story of the state of affairs for this major league IT pain-in-the-rear-end. Most of you reading this probably already have a bot or malware running on a computer in your organization. These insidious beasts are being produced at a rate far faster than the software to recognize and eliminate them. Some of these are harmless, but some can be exposing critical flaws in your infrastructure that can be exploited by an individual with the appropriate skills facilitating access to your most confidential and private data. And, yet, the industry salaries for individuals with the capability to protect your networks and systems is below that of many other roles, such as Database Administrator (DBA), programmer, architect, virtualization engineer, storage engineer, etc. Obviously, protecting your information assets must be of minimal concern to you or you would be out seeking the skills of individuals or businesses that can provide you, minimally, with the knowledge that you have data leakage and, best case, close the holes and eliminate the problem.

It looks like Healthcare IT is shaping up to be a major land grab for software and hardware vendors next year. It seems that rising health costs and the government's emphasis on lowering costs via electronic health records has moved the IT target to this vertical. I have seen a number of major software vendors establishing Healthcare IT groups within their sales and marketing organizations in an effort to ramp up for what is deemed to be the next great sales frontier. Well I hope this report doesn't put a damper on those visions of grandeur. The report concludes that "health information technology has a modest impact on process measures of quality, but no impact on administrative efficiency or overall costs."

Here's one that my sources say to keep an eye on, IPv6. IPv6 is the next generation Internet Protocol. Many service providers will be switching to this standard soon because it provides them much more control over the number of Internet devices they can directly address and fixes many of the issues of IPv4. However, many of the IPv6 protocol stacks are new and have not been tested under full stress of a production environment. If you remember, it took Microsoft something like ten years to get their IP stack to a point where it was robust and mature. The IP stack is at the heart of every device that connects to the Internet. Changing this protocol is going to be slow and painful, but not changing soon is going to cause major disruptions in service as service providers are forced to use IPv6->IPv4 conversion, which at gigabit speeds is tedious and adds latency, not to mention that it will add overhead to the router for maintenance of multiple tables and increases memory consumption.

8Oct/099

The Role of The Business Analyst in an SOA World

Those of us that are part of SOA-related projects where traditional business analysts (BA) are involved often find ourselves frustrated by the incongruence between the analyst’s approach to requirements gathering and the SOA design.  The problem arises because SOA models functionality of a business across multiple boundaries, whereas the business analyst wants to focus on a user’s needs.  One focus is tactical and the other is strategic.  However, more than this key difference, certain aspects of the tactical requirements overlap with the strategic requirements; specifically with regard to service boundaries.  Thus, important business rules that are relevant to the definition of a particular service are buried among hundreds of irrelevant (to the SOA goals) requirements and the SOA architect is forced to mine these requirements like a miner mining for gold.

In figuring that someone else must have written on this topic, I visited my favorite Web search engine and pulled up the following article: “The new business analyst talks SOA”.  I was surprised to find this content on Network World given the nature of the topic, but quickly realized that the author thought of SOA as an application architecture instead of an aspect of Enterprise Architecture.  So, it was not much more of a surprise when they recommended that business analysts needed to become more savvy in SOA by learning BPEL, SCA and SDO; perhaps the worst advice I have ever seen regarding this topic.   The last thing we want are the business analysts talking about SOA, let alone SODA aspects of SOA.

Still, the article had one point correct, business analysts had better be reading the signs and acclimating themselves to a different type of conversation with their users.  Moreover, I believe SOA is a game changer in the way that we collect requirements going forward.  For businesses that really want to be successful with SOA, the first conversations that need to be had are with the key business stakeholders, and an Enterprise Architect with SOA experience must be present and facilitating these discussions.  This will be the basis for formulating a service model, which will then guide all future system designs.  I would also engage a business process engineer to start analysis of business processes that directly impact the effort.

Ultimately, if a BA is able to make the transition to SOA mindset, then they might be a good candidate to drill down and analyze the requirements for the service contract and vocabulary for each service.  Otherwise, an SOA architect should really handle these efforts.  Which begs the question, what is the role of the BA in an SOA world?  I believe there is a need for really good subject matter experts that can work with the Enterprise and SOA architects to fully define the interactions between business functions and, perhaps, to capture the usability models.  However, even in the case of usability, a usability expert will offer more insight into how to present information to the user than the BA.

Overall, my analysis is that in an SOA universe, the role of the BA is greatly diminished unless they can adapt to the change in role and gain an understanding of how to facilitate requirements gathering in a much more compartmentalized manner as outlined by the SOA architect and the business process engineer.

1Sep/0914

Keep Your SOA and BPM Initiatives Separate

Not to beat the dead horse, but during a discussion the other day with a fellow SOA cohort, I came to a realization for the reason SOA & BPM get inextricably tied together in some individual’s thoughts. I’ve written and blogged before on how SOA & BPM have very different goals. SOA is about application rationalization via a service metaphor and BPM is about business process analysis and optimization. The fact that they are discussed in the same breath leads one to believe that they are inherently related, when in fact they are not.

That said, as one performs a top-down analysis of their business as part of a BPM initiative, they are going to discover they need a framework to assist in implementing new business processes that cut across departmental and other organizational boundaries. Clearly, one of the greatest areas for improvement within in an organization is across these organizational boundaries because process improvement tended to be an intra-departmental exercise. When the process needed to cross an organizational boundary, the political, geographic, technological, etc. hurdles led to inefficient crossings.

Historically, SOA and BPM rose in popularity at or around the same time. SOA, led primarily by technological practitioners, responded to the needs of BPM practitioners for a framework to capture and implement newly-designed and efficient cross-organizational business processes with technology. However, for BPM, technology is the least of the problems. Indeed, BPM’s biggest issues are political and geographic in nature. A process that needs to cross continents or rely on participation of a department that is resistant to change pose a far greater problem to process optimization than not having a web service available to invoke.

Still, there is seems to be a natural gravitation toward SOA as providing the necessary framework to capture and implement new cross-organizational business processes. Most likely it is the service façade that allows various business functions to be exposed as technological assets accessible over common Internet protocols. After all, what better way to create a business process that crosses organizational boundaries than tapping directly into the data and systems that support those sub-organizational areas?

However, it’s important to note that SOA should not be viewed as the nail for BPM’s hammer, as is all too popular a notion today. It is not an SOA if you decided to wrap a few legacy systems with web services so that you could easily build out an automated business process. That is just part of your BPMS effort.

This entanglement of SOA and BPM into a single effort is fraught with problems and failure. Each initiative should be undertaken separately and with definitive goals that do not list each other as one of the outcomes. If as part of the rationalization that SOA provides, there happens to be some services exposed that simplify the implementation of a particular business process, then that would certainly be a slam-dunk. However, SOA and BPM each have their own metrics of success and their own barriers to success. Combining them into one, well, the words “boiling the ocean” comes to mind.

22May/093

The Relationship Between SOA, BPM & EA

A colleague recently sent me some IBM propaganda on SOA, BPM and EA. Discussing my opinion of the white paper with him sparked an idea for a blog entry about the my opinion on the relationship between these three methodologies.

Okay, let’s dive into the meat of the issue. What, if any, is the relationship between SOA, BPM & EA? First, some quick definitions:

BPM is a practice that focuses on identifying if a business process is operating within normal operating ranges. How can you tell that? First, you identify some key performance indicators (KPI) that you will use to measure your business process (this implies you actually understand your business), next you have to baseline your current business process; lastly, you modify one variable at a time to see the impact it has on the process. Since this last step can have financial impact for your business, you may want to consider using simulation to assist in this process.

SOA is a practice that focuses on modeling the entities, and relationships between entities, that comprise the business as a set of services. This can be done on a small or large scale. Typically, the relationships in this model represent consumer/provider relationships. Doing SOA correctly implies you are taking a top-down approach. I’ve seen/read views that discuss the bottom-up approach to SOA and I don’t believe the results of that represent SOA. Perhaps it’s a component model, but not a services model. The value of SOA is that you are aligning IT with the business using this architecture methodology.

Finally EA is the ‘Big Kahuna” of architecture practices. It attempts to get the architect(s) to take a holistic approach to thinking about the organization approaches delivery and support of solutions on an enterprise scale. The goal of cataloging and modeling at this scale is that you can see “the forest from the trees”. It’s very easy to think about solutions in your organization based purely upon need, but you will end up with a set of disparate and disconnected silos. Cataloging that need in an EA enables the organization to recognize consistent patterns and consolidate around them. Thus, operational costs are reduced, redundancy is avoided and time is spent solving the unique aspects of new problems rather than continually reinventing the same solutions over and over again.

Now I will provide my opinion on the relationships between these methodologies:

SOA & BPM: SOA & BPM are methodologies, not tools or technologies. It’s irrelevant if SOA suites can do BPMS or BPMS suites support SOA. There is no inherent relationship between these methodologies just because vendors discovered that that they can use Web Services as a means of execute a task within a business process. Web Services is not SOA, it is merely a standardized approach to accessing functionality on remote systems.

However, a well-designed SOA can simplify BPM by enabling rapid business process modeling that only needs to go as deep as identifying the right service rather than having to identify the entire sub-task. SOA can also simplify BPM by denoting in the service the types of KPIs that the service maintains for itself. This requires full understanding that a service is a measurable unit and that metrics are a key component to development of the service contract. If you can’t measure it, it’s not a service!

EA, SOA & BPM: SOA and BPM are views within the enterprise architecture. They don’t replace the need for EA and they cover only a small subject of EA’s requirements.