• Blog
  • About
  • Archives

elemental links

brenda michelson's technology advisory practice

Archives for October 2005

Open Source Considerations

October 25, 2005 By brenda michelson

As I’ve mentioned in an earlier post, I believe open source absolutely has a place in the enterprise; and that enterprises have some responsibility to contribute back (resources, code) to the open source community. Of course, on both ends, you need to be smart. Understand the implications of licensing, IP (yours and theirs), support (yours and theirs), code quality, security and stability, project adoption and longevity, and total cost – because nothing is really free.
In that same post, I also promised ‘more another time’. That time is now. Last week, I wrote an Open Source Considerations report for PSGroup. In the report description (and introduction), I state the following:

Since every enterprise is different, we believe it would be irresponsible to make blanket statements as to where you should, or shouldn’t, be using open source. Instead, in accordance with our standard research practices, in this report we provide insights on open source considerations for you to make informed decisions for your business.

With that, in this post, I’m excerpting those considerations. For the complete report (free), go here. Keep in mind there are some “no-brainer” uses of open source, in which case these considerations might be overkill. Again, you have to make the right call for your business. Examples of those are:

Using open source purely for R&D to get familiar with a new technology.
Open source projects which are de facto industry standards, such as Apache Web Server
Open source embedded in commercial products, such as Apache Axis.
Low-cost infrastructure (Web server, application server, and database) for development and initial test environments from well-established providers such as ObjectWeb, JBoss, and Apache.
Developer and administrator tooling (Eclipse, Perl, PHP) that stays within the enterprise.
Non-modified implementations of commercially-backed operating system distributions (Linux, Solaris 10).
The Excerpt: CONSIDERING OPEN SOURCE

What specifically should you be looking at, as you consider open source beyond the no-brainer uses? You need to look at three things: your project, the open source project, and your enterprise IT environment.

First, Your Project. Does Open Source Make Sense?

The Risk Factors. As with any IT project, you need to ask yourself the big questions. What is the purpose of this project? Does it provide strategic advantage? Does it provide core (critical path) processing? What are the service level requirements? What are the security requirements? What are the compliance requirements?

If your answers point to a high-risk project, then open source isn’t the right choice, especially for an initial foray. However, you still may find that components of the project fit in the no-brainer category. Remember, in a modular, service-oriented world, you don’t have to make all-or-nothing decisions.

License Restrictions. If your answers don’t scream risk, and the idea of an open source jumpstart (code base and low financial entry) is appealing, then you need to think about the license obligations you can live with. (The assumption here is that your project will modify, extend, or create a larger work from the open source code.) The questions: Will you be mixing proprietary and open source code in your solution? Will you implement any components outside of your walls? Is there a competitive risk to your business if your code is released to the community? If you answered “yes” to any of these questions, open source may still be an option, but GPL licensed code might not be.

Evaluation Framework. At this point, you’ve screened your project to determine if open source is a viable consideration. Now, you need to perform normal project activities to identify requirements, create an evaluation framework, and prepare a short list of candidates. For commercial products, PSGroup recommends (and produces) evaluation frameworks with the following six aspects:

Features and Functions
Design, Development, and Deployment
Management and Monitoring
Architecture
Product Viability
Company Viability
For open source solutions, replace the last two aspects (product and company viability) with an open source project viability assessment, as described next.

Second, The Open Source Project. Is it Viable?

As mentioned earlier, most open source projects are not undertaken with the goal of enterprise consumption in mind. So, in your evaluation of the open source project, you need to think about how to resolve the gap between project and production-ready product. Typical items to be resolved are: documentation, installation scripts, product roadmap/evolution, patch and release management, systems management hooks, and problem/emergency support. These items might be resolved by the project community, by a commercially-oriented ecosystem, by your staff, or most likely, by a combination of all three.

Specifically, as you evaluate an open source project for viability, you need to get answers to the following:

Project Origin and Objective. Did this project evolve from a group of programmers solving a problem for themselves? Is this project an industry sponsored technology reference (or proof of concept) implementation? Is this project a welcome donation (Eclipse) of commercial software that will form a common foundation? Is this project a dump of commercial software, which has reached end of life?
Maturity. When was the project established? What is the current project release? What is the adoption rate? Is adoption building, level, or declining?
Backing. Is there money behind the project? How much, and from who? Who is the community host? Is the host credible?
Project Leadership. Who are the project leaders? What is their industry track record (open source, commercial, and/or enterprise)? Is the project well managed?
Community Engagement. Is there an active community of developers, testers, and end users? Are there forums, email lists, and FAQs? How often is the source code updated? Are bugs reported? Fixed?
Project to Product Gap. What is the gap? Does the project just consist of source code? Are there binaries and installation scripts? Is there documentation? Does the documentation cover the architecture, code, and/or end use? How often are patches released? Can patches be applied incrementally? How often are releases available? Is there a project roadmap? Are there administration scripts? Are there hooks for systems management? Is there a security model? Are there programming APIs?
Commercial Ecosystem.* Is there a commercial ecosystem––consulting, training, code validation, distribution management, support––for this project? Is it cost effective? Are the firms viable? Is the ecosystem expanding, level, declining?
Code Base. What language(s) are used? Are open standards used? How is the code quality? Is there a modular, extensible design? Is the architecture apparent? Are there APIs?
Testing Practices. How does the project test? Is it a formal process? Are testing assets distributed with the code base?
License. What license(s) is the project under? What are your rights and obligations? Are there dual license options (open source and commercial)?
Commercial Conflicts. Are there any commercial conflicts (the project, and/or your business)? Does the code base have a questionable history? Is there any pending litigation?
Competitors. Who competes with this project? Are the competitors open source? Commercial?
Chatter. What are people saying about the project? Check email lists, blogs, community boards, and trade press for participant (developer, end-user) and observer (press, analyst, competitor, partner) chatter.
Third, Your Enterprise. Is There a Fit? Is It the Best Fit?

In this last step, you need to determine if the viable open source project(s) are a good fit with your enterprise. While you are concerned with the normal factors of architectural, operational, organizational and budgetary fit, the lens is slightly different. Essentially, you are mixing buy and build models. There is the code base jumpstart of a commercial purchase, and the ongoing care and feeding of a build.

Could You Survive Alone? With this in mind, the first big question is, “If the community dried up, what would you do?” Can you support this software? Is that the best use of your resources? Would your business be at risk?

Can You Span the Gaps? Next, you need to address any gaps discovered between open source project and production-ready product. Does the investment (time, skills, people, and dollars) to close that gap fit your enterprise plan?
Are there opportunity costs? Are you willing to make a contribution (people, dollars, code) to the open source community to bridge this gap?

Do You Fit in the Open Source Community? Finally, you need to consider if your enterprise fits into the open source community. After all, they are doing the initial work! Are you willing to participate in the community, contribute to
the project’s evolution? Donate back some of the less cool, but very important, production readiness deliverables?

Best Fit? After determining the fit of the open source solution, you then need to weigh your options. Does an open source solution provide a better/worse fit and value against competing commercial and in-house build solutions?

As mentioned at the onset, there won’t be a single right answer. However, there will be a best answer for each business.

* Some big-name vendors––IBM, SAP, Novell, BEA—are participating in the commercial ecosystems for open source. There are also open source-specific providers such as RedHat, JBoss, SugarCRM, SpikeSource, and SourceLabs. As projects become popular, ecosystems are evolving to feed enterprise appetites. This burgeoning commercial market is particularly interesting to watch, given the roots of open source – individuals solving problems for their own benefit (use, challenge, education, community experience). [well, at least I find it particularly interesting…]

Filed Under: enterprise architecture, open source Tagged With: archive_0

events/travel over the next few weeks

October 24, 2005 By brenda michelson

At the moment, my plans have me at the following events/locations in the next few weeks:

10/28 Maine’s Annual Technology Conference – helping out the home team!

11/1-11/2 Open Source Business Conference in Newton MA

11/7-11/8 InfoWorld’s SOA Executive Forum in New York

11/14-11/16 a client gig in Seattle

If you find yourself in the same place and want to chat, drop me an email: bmichelson at psgroup dot com or add a comment to this post. 

Filed Under: circuit

(Finally) My Notes from BEAWorld Santa Clara

October 10, 2005 By brenda michelson

Unless you are a reader of PSGroup’s research service, the combination of my last travel distressed post, and my subsequent blog silence may leave the impression I was still stranded in a connecting airport. However, I’m happy to report I eventually got out of Dulles, and made it to Santa Clara for BEAWorld on Tuesday and Wednesday.

At BEAWorld, I was in both of my roles, architect and industry analyst. As an architect, I sat in on sessions, and chatted with fellow attendees about their IT challenges, and their impressions of BEA’s (and competitors’) offerings.

As an industry analyst, I was able to meet 1×1 with members of BEA’s executive team. Not surprising, I was asking questions related to BEA’s architectural intent. In addition, I was curious as to any (early) insights on how the SOA vision/bet was going.

This (long) post starts with a high level analysis, and then drops into some quick notes/observations from the conference.

The Analysis Piece – BEA’s BIG SOA BET

As most know, BEA’s vision/quest is to become the real world leader in SOA. In such, BEA has devised (and is delivering on) an interconnected three-part strategy. The strategy starts with BEA’s SOA Domain Model and is supported by advisory services, and the (Aqualogic) services infrastructure. [For more on the specifics of BEA’s vision, check out BEA’s site and/or my April PSGroup report: BEA Answers the Vision Question(s).]

BEA is betting big that SOA achieves mainstream adoption in the next 3-5 years. And, that BEA can win the same proportional share of that mainstream SOA market, as they hold in application infrastructure. If this happens, BEA has an excellent chance of remaining independent. If not, then BEA will most likely be scooped up by an application vendor, infrastructure provider, or, as Phil Wainewright at Loosely Coupled suggests, a service provider.

A critical success factor for BEA is to guide their current customer base “up the stack” to SOA — SOA that is, on BEA’s Aqualogic Services Infrastructure. In such, I believe BEA needs to do three things (really well):

1. SOA Evangelist First, Product Seller Second.

First, BEA needs to be a “real world” SOA evangelist first, and the seller of SOA infrastructure products second. This evangelism should include: what SOA (the architectural strategy) really is, what SOA is good for, how to (incrementally)
get there, and the business and IT implications.

BEA did a pretty good job of this at BEAWorld. I attended some good “Making SOA Real” sessions hosted by BEA’s SOA Practice Leaders on Organization and Governance, and an SOA Roundtable. The messages were on target: SOA is an architectural strategy, SOA success requires collaboration, governance and service catalog/portfolio plan, SOA is incremental, SOA is not a “right click architecture” (service != java class), SOA does not require Web Services, and SOA does not require an ESB. Although on the last two points, Web Services and ESB, the BEA presenters (SOA practice and Aqualogic product) did state SOA would be easier and more sustainable using both Web Services and an ESB.

Also, Bruce Grahams, BEA’s VP of consulting, hosted an SOA from Pilot to Production Panel in the general session. The panelists were John Peebles, vice president, online marketing for Cendant Car Rental Group, parent company of
Avis and Budget; Doug Saucier, vice president of enterprise architecture services, Sony Pictures Entertainment; Vinny Carpenter, lead architect for the Wells Fargo Advantage Funds; and Patrick Holmes, senior principal engineer, IT
architecture group, Intel Corporation.

I was pleased to see this session on the agenda – I enjoy hearing real world (business-driven) technology stories. Most often, these folks (like myself), found themselves using SOA (although not labeled as such then) because it just seemed
logical for their business. For me, the best SOA evangelism is from IT professionals speaking in business contexts. You know the “Here’s what I did, and why. Here’s what happened. Here’s what I would do differently. Here’s what I’m thinking of next…” type of stories. Unfortunately (at least for me), there was only about 30 minutes for this panel, so a lot of great information went unsaid. Although, all is not lost, Vinny Carpenter posted what he would have shared, had there been time.

2. BEA’s SOA infrastructure must “work”.

As I wrote for the PSGroup September 29 research service, BEA has a fiercely loyal customer base. Without exception, every developer, administrator, architect, and IT manager I spoke with is looking to BEA as its first-choice provider of SOA infrastructure. Why is that? BEA has a strong track record of delivering application infrastructure (Tuxedo, WebLogic Application Server) that works. I use the term “works” as a developer, architect, or administrator would, in that BEA’s application infrastructure products focus on, and deliver, the “-ilities”–reliability, scalability, manageability, and performance. For BEA to win its bet, it must ignore the SOA feature/function foot race, and concentrate on receiving the “it works” stamp from customers for its services infrastructure.

3. BEA needs to keep its current application infrastructure customers (WebLogic and Tuxedo) happy.

Let’s face it, in an open standards-based world, the power shifts to the customers. If you adhere to the J2EE spec, you aren’t locked into any particular vendor’s application server. It is relatively easy to switch. And, the switch can be to open
source infrastructure, cutting out all the upfront acquisition costs. So, its only natural, IT decision makers are asking their vendors “What have you done for me lately?”

Innovation

BEA’s answer is continued technology innovation, and broadened appreciation/support of enterprise IT realities. On the innovation, BEA introduced performance improvements to JRocket (JVM), predictable garbage collection for WebLogic
(bringing J2EE to real-time applications, such as stock trading), and hot deployment (zero downtime) to WebLogic. The hot deployment demo – deploying a new version of an application, without breaking existing sessions – really got the audience’s attention. Having lived through my share of 3:00am implementations – to not interrupt the business – I could definitely see the feature’s appeal. There was also significant buzz on the real-time edition.

Enterprise IT Realities

On the broadened appreciation/support of enterprise IT realities, BEA gets (and supports) that IT environments are heterogeneous. This showed in a few ways. First, BEA’s SOA strategy has been devised recognizing that IT portfolios are (and always will be) comprised of assets implemented using a mix of technologies, platforms, and architectural styles.

Second, BEA understands that most enterprises will have some open source application servers in the mix. WebLogic 9 allows for the administration of Tomcat and Geronimo application servers from within the WebLogic Console.

Third, BEA understands that not every developer is (or should be) a J2EE expert. In situations that don’t require the full complement of J2EE technologies, but still have J2EE implementations, enterprises are turning towards open source frameworks such as Struts, Spring, and Hibernate. Since the frameworks are part of the deployed code base, there is always the risk (if the community dries up) of having unsupported production code. In an effort to mitigate this risk, BEA has announced support for the J2EE frameworks (Struts, Spring, Hibernate, Beehive) being embraced by their customers. This move resonated strongly with developers at the show.

Ok, that’s way more analysis than I intended to write… Suffice it to say, BEA is working the odds to win its SOA bet. Now, for the notes…

Quick Notes/Observations from BEAWorld

My Conversations with BEA Leaders

  • When I inquired on the Tuesday morning Microsoft/JBoss announcement, it was shrugged off as a “non-event”. Not an attack by Microsoft on BEA or IBM, but rather a standard practice (product integration optimizations) in a heterogeneous world.
  • Talking to Mark Carges, BEA’s CTO, it is obvious a huge part obvious BEA’s architectural premise, is in delivering stuff that “works”.
  • Continuing on architectural premise, talking to Shane Pearson, BEA’s VP of Product Management, I learned that BEA thinks about services infrastructure in a service-oriented manner. The ESB packaging has services for mediation, routing, service composition, but not business process management. BEA sees business process management as a service that integrates with the ESB.
  • I had the chance to meet with Rhonda Hocker, BEA’s CIO. Not only does BEA “eat their own dog food” (WebLogic App Platform: App Server, Web Logic Integration and Portal, and AquaLogic); the internal IT organization, as a customer, contributes ideas, requirements, and even code, to the product line. Rhonda described her organization’s SOA evolution, which like many early adopters, started a few years back. The problem Rhonda was trying to solve was a familiar one, freeing information trapped in packaged applications, without ripping and replacing. Not surprisingly, Data Services and Portals play a key role in BEA’s internal IT architecture. For more, read page 2 of this pdf.
  • In my quest to find content for a unified (but reasonable) SOA methodology, I asked one of BEA’s SOA Practice Leaders what BEA was doing to help customers discover and define the right services. At first, I scared him with
    the word methodology – he thought I meant tomes of documentation. When I assured him that wasn’t what I meant, he told me BEA has exercises in their SOA workshops to get at the services catalog (my term). I hope to get a look
    at these exercises in a follow-up meeting.
  • While squatting at a “reserved for PR table”, I had an interesting conversation with a principal player of the WebLogic Communications Platform. While I don’t cover telecommunications (and won’t try to fake it) – as an end consumer, I think some of the SIP enabled services (triple-play, find-me, follow-me) are cool. What I enjoyed most about this conversation was my fellow squatter was talking in use cases. He put the product in “what it can do for me” terms. [More coming on the use case thing in a future post.]

What I liked – Real World and Customer Loyalty

  • A real world IT perspective to their strategy: IT is heterogeneous, SOA needs to be thought of holistically (see domain model), planned strategically, and implemented pragmatically! Don’t buy what you don’t need, but don’t box
    yourself in. Also, if you haven’t considered the organizational issues and governance, you’re doomed. So true.
  • The attendees I spoke with (architects, developers, administrators, IT leaders) have a fierce loyalty to BEA, because, simply “the stuff works”.

What Frightened Me – An SOA Gray Area

More than one presenter referred to a future in which enterprises will have “thousands or tens of thousands of services”. Ok, sure they are trying to sell a registry and SOA management infrastructure, but 10,000+ services?

In drilling in on that point (with a couple of BEA folks), it became clearer that we had entered one of many SOA gray areas. This one had to do with granularity, compositions, and service types. Essentially, it came down to this: If future applications are really assemblies of scenarios (compositions of services, business process and events), and each of those scenarios is implemented as a service, then there could be 10,000 services. But…I think we (the industry) need to be clear about what we mean (when we say service), and offer rules of thumb on reasonable size service catalogs, by type, level of granularity, and perhaps logical versus implementation.

Interesting Asides

  • During “The Enterprise Service Bus: Core to Creating a Liquid Vision for SOA” BEA didn’t come out and say, but I thought I heard “Java Business Integration (JBI)”. It was in the ESB roadmap plans as “Pluggable Extensibility”. As you’ll recall BEA abstained from the JBI voting. Of course, it could just be wishful thinking on my part – I like the idea of a backbone with pluggable services. When I leaned over to the analyst next to me and said “sounds like JBI”, he thought not. Mark Carges, BEA’s CTO, told me BEA is watching JBI, as is their practice on early standards.
  • Jonathon Schwartz spoke (eloquently) on the participation age, power at the edges, openness, and inevitable choice. Jonathon then proceeded to pitch Sun’s Enterprise Java Tools and Application server – apparently providing “choice on the spot” to BEA’s developer community. (perhaps I should take a sales lesson from him)
  • Burt Rutan’s presentation on his SpaceShipOne program was great! I’ve never had the inclination for space travel, but I’m glad there are people like Burt, pushing the envelope and pursuing their dreams.

Filed Under: services architecture, soa

Brenda M. Michelson

Brenda Michelson

Technology Architect.

Trusted Advisor.

(BIO)

  • Email
  • LinkedIn
  • RSS
  • Twitter

Recent Posts

  • Experts Sketch
  • PEW Research: Tech Saturation, Well-Being and (my) Remedies
  • technology knowledge premise
  • The Curse of Knowledge
  • better problems and technology knowledge transfer

Recent Tweets

  • “…where the process of drawing itself can take us. We can follow a suggestion, a squiggle, shadow, or smudge, and s… https://t.co/oRg0x2LoXG November 30, 2022 5:05 pm
  • On the waiting list for Post, join me (on the waitlist) via https://t.co/U8wYK707f6 November 24, 2022 4:17 pm
  • Meet the longtime librarian being honored at the National Book Awards : NPR https://t.co/S44VQeJg83 November 13, 2022 2:51 pm
© 2004-2022 Elemental Links, Inc.