Jason Lenhart

Yesterday, after sipping my favorite Moroccan Mint tea at my favorite tea bar; Kristen (one of the owners) set me aside to break the news… Remedy Tea Bar is closing. My heart sank. I love this place and cannot believe it will be closing. Where will I go to get quality product like what the two owners served (with a smile every time)? I guess there are always the larger stores – but Remedy was such a great local Center-City establishment. Within trendy tin-metal cans, Remedy always had a fresh selection of teas. For roughly four years, I would routinely find myself in deep thought selecting which tea to sip. Like Calgon – this establishment as well as the tea had powers to ‘take me away’ from the bad of my day.

I have nothing but fond memories of going to Remedy as a way to get thoughts in order, work on grad homework, and in general just work. Many of my best ideas have originated from Remedy and I believe this is due to the great atmosphere the owners encouraged. It was a very relaxing environment, with great snacks, awesome tea, free wifi, and most importantly always played the best music.

Overall, I believe this to be upsetting as this is the first time in my life where an establishment I recommend and regularly enjoy is closing. The good news is that the website will remain open for visitors to purchase tea. However, it still does not make up for the loss of the bar.

Kristen and Courtney - thank you for supporting my caffeine habit over the years. I wish nothing but the best for the both of you in your future endeavors.

I recently completed reading JavaSpaces Principles, Patterns, and Practice and found it to be a quality book on the subject.  This was a great introduction to the concepts and implementation of Space Based Architectures. 

Coupled with the introduction are plenty of great examples, applicable to the Web 2.0 architecture being evangelized these days.

One thing that was really neat about this book was the foreword by David Gelernter, the father of Space Based Architectures.

Last night my wife and I enjoyed a nice evening out with friends - dining at Osteria.  The menu is fairly diverse and found some of the more exotic items not so daring in taste.  For example the octopus (normally I would never take such risks) was unlike what I had expected - dare I say “it tastes like chicken”.  The pizzas were great as appetizers and my Tuna Scallopine was delicious (very fresh).  The service was great as we had a waiter that seemingly had Dane Cook down pat (mannerisms and appearance) — my wife kept quoting lines from one of her favorite Dane Cook movies.  Overall, excellent restaurant but certainly not low-key as reservations are booked a month in advance and the place is crowded.  On the downside - the parking situation is a bit of a game - You can wait for a prime spot on Broad street or park in one of the more risky alley ways off Broad — recently having some wheel covers just stolen from my car and costing me several hundred in replacement has me waiting for the prime location.

My cousin Mike Lenhart, recently had a USA Today video story about a foundation for which he founded, Getting2Tri Foundation. As founder, he is providing coaching, training, and mentoring to physically-challenged (PC) athletes in the sports of swimming, running, cycling, and triathlon. The foundation is specifically addressing the needs of individuals with limb loss, paralysis, muscular, or neurological disorders. What I find important and exciting about his work is how he is fostering communities of support for PC athletes as well as knock down any perceived barriers. Mike was once a technical officer in a well-known company - but he had a different calling and passion. I applaud his effort to make a difference in people’s lives as well as promoting fitness. Take a look at the video below.

Take a Look at the Video by Clicking on the Photo Below:

Mike Lenhart, Founder of Getting2Tri

If you would like to make a tax free donation it can be done by clicking here.

In the last couple of days I was asked to build a presentation regarding lessons learned, observations, and recommendations for the last project I technically directed and managed (doing this with an excellent group of peers I helped to recruit). In general, it got me thinking about SOA and the decisions we were making both successful and lessons learned.

First off, I could not help but think back to the fanfare of the project kick-off (some 3 years ago), the term SOA being utilized in every presentation. Whether these presentations were presented to the greater organization or within technical/non-technical conferences — the term SOA was certainly overloaded in an extreme manner.

As the project progressed, one thing that remained was the fact that technical leadership never lost site of the core principles of SOA - more importantly how it is nothing new or exotic. As a published friend of mine stated:

“Companies have been ‘doing SOA’ for many years, even before the term was coined, using technologies as diverse as CORBA and JMS. Think of it as a pattern, or an architectural approach in the same way as distributed object-oriented systems. It has its place in any good architects toolbelt and we’re finally coming to grips with it as an industry.”

I have a tremendous amount of respect for Mark Little - and have always felt his opinions are “spot-on” (to steal a quote from Ocean’s Thirteen).

So why are we just now seeing large studies that indicate that SOA is not working in most organizations? I mean - it seems so fundamental that Organizations would want to achieve certain key benefits (a sampling of the key benefits I dug up in past presentations, re-termed by me in parenthesis):

• Leverage high levels of interoperability to seize new business opportunities (fancy term for ability to build composite applications)
• Customize/leverage existing assets (not have to start from scratch on every project)
• Be able to leverage a best of breed landscape for software, data, and infrastructure (knowing that changes in the environment have been properly abstracted or loosely coupled such that these changes can occur with little to no impact in the consumers)

So why is it not working — who or what would impede these benefits from happening? Certainly there is a cultural aspect to this question which I am not going to address on this post but I will offer a more fundamental approach to the model or architectural style that SOA promotes, as there seems to be little question that the core ideas behind SOA are the right ones (they have been around for decades) — this approach, I believe to offer large organizations a better chance at success.

I think the issue with SOA is how so many organizations/people have gone about the design and implementation . The architecture community loves to review ‘reference implementations’, so what would a great example of a SOA design and implementation look like? I don’t think you really have to go far to realize it — most folks are using these implementations in their daily lives. Google with all the Web APIs which tap into Maps and Data, or Amazon and their successful Web Services, or how about the new social phenomena of Twitter that is getting 10 times more use through its APIs than its interface. These are all outstanding implementations of SOA. Furthermore, it is even harder to argue their success when you begin to look at all the “software mash-ups” currently out there in the Global SOA.

Getting back to my retrospective - how come we do not see this level of success in the Enterprise? We were seeing success - but shouldn’t the rest of the organization be sharing in it? I guess these are questions I was coming back to in my head as one of the things I would often hear:

“Well if we could start over - and use any technology we wanted - seemingly had an endless budget - we would have that success as well”

I don’t believe that only new implementations (with tons of money) can enjoy the fruits of an SOA implementation done right. There is a sort of implication in that statement that SOA is tied to the technology. I disagree - lets go into deeper detail.

Going back to my ‘reference implementations’ on the web, I am of the belief that organizations are often aligned in a way that is fundamentally unlike the web. IT organizations have long been plagued as a ‘cost center’ rather than a strategic asset. Looking at the above examples it is clear that there is a focus on consumption and openness as key essential characteristics to building an internal partner ecosystem/community. There certainly was not a big-bang approach to their strategy but it fostered a community of growth that is returning higher levels of ROI. The large IT organizations I have consulted/worked within are very effective for their perspective class of business problems (mainly providing a long term safety of corporate domain knowledge and systems) - but when SOA is being seemingly shouted from the mountain tops like a Ricola commercial - by its very hierarchical organizational make-up across various LOBs weighed against varying consumer dynamics, consumption and then taking into account the lack of easy to process data, forest of relational databases, and silos of proprietary applications — openness and consumption take a backseat to bonuses, perceptions, and plain ol’ ‘get it out the door’.

I believe proper design and implementation can allow these sort of internal ecosystems to develop independent of the organizational dynamics. What I have found is that by not always taking the ’standards approach’ has yielded good bit of success. Most notably in the approach and delivery technique to allow openness and consumption - not letting this be forgotten or ignored in favor of:

• Security Department rants, confusing openess consumption as an attack on security

• Groups/individuals spreading FUD about ‘if you are not using WS-* you will be refactoring your whole codebase very soon’ - thus freaking out stakeholders

The concept that has worked best has been best coined by Nick Gall as Web Oriented Architecture (WOA). REST/WOA is placing the focus on the resources and not on the services which is often where we see all the SOA methodologies taking the people who are performing the implementation

By organizations allowing and fostering their organizations to adopt WOA at a grassroots level - the openness and consumption will naturally progress. How can I make such a lofty assumption? - I have both seen first hand and in some cases felt the pain of how this direction was/would-have-been the better decision. This is especially true when you see companies make acquisitions and want to bring their business onto your platform, incrementally. Some observations:

• Instead of a few point services that typically have a context of usage that the LOB could only use due to constraints like WSDL (yes I believe one of the core tenets of loose-coupling in SOA is broken due to WSDL) - enterprise data can be tapped into through REST based resources (just like the web), which will allow any application to consume via HTTP and XML. Note: Even higher levels of access can be achieved via syndication which establishes the openness.

• Open Web APIs - exposing data to customers will often get LOBs out of the presentation domain. Data is king in the enterprise, why must everyone provide a front-end to every piece of data in the name of:

‘I cannot have you just willy-nilly accessing our data’ — so a front-end justifies this?

ACLs can be appied to Web APIs as well. It is important to note that openess is not a code-word for the lack of security - these are orthogonal to the implementation.

Next to an organization’s people, data is the most important asset - it should be managed like a money-manager manages a portfolio. Treating the data as restful resources will inherently offer productivity gains via external frameworks and tools. From a management perspective - I believe that it is easier to conceptualize the make-up much easier therefore people will not get caught up in a federation of relationships. Also, I observed that making the data a resource offers the opportunity to better engage you business with the types of tools they use everyday. Thus offering a medium of collaboration that helps get the business-partners out of the ‘IT is a Cost Center’ mentality. The business folks are writing code every day (whether IT knows it or not they do) — it is untested code and placed into production immediately. A quality example of this is the explosion in use of spreadsheets to perform higher level functions - whole departments will build out templates and email them around, using them to perform activities whereby they do not have to explain to IT (e.g. accounting). My point is that more so than ever before - we in the technology community are blessed (and I use this term loosely) with a business community that is operating a higher level of competence around technology - they can conceptually bridge ideas into the digital domain much more easily. That said, with tools like blogs, wikis, twitter, widgets, etc… this should enable better adoption of WOA because you are driving the consumption of the resources through the mainstream.

Overall my observations - are best summed up in the following:

Like previously stated SOA is an approach that the greater community has come to grips with, conceptually it has been around a long time - but the benefits will take much longer for the enterprise to realize (across the board) as the current enterprise techniques lack in grass-roots support. Some assumptions in the design of services and implementation of standards should not be so basic to the organization. Techniques that have the by-product of openness and consumption; using WOA, are the ones to promote and implement.