By Don Worthley on 11/14/2007 1:42 PM

There's been a lot of hype around Google's announcement this past week regarding OpenSocial, a new open Application Programming Interface (API) for connecting to social networking applications such as LinkedIn, MySpace, Ning, Oracle, orkut, Plaxo, Salesforce.com, Six Apart, Tianji, Viadeo, and XING. Together, these companies represent around 200 million users, so the potential audience for social networking applications built on this API is substantial and the user base is growing rapidly every minute. In fact, as soon as I watched the well planned and scripted campfire video, I sent an email to my brother who had sent me the link exclaiming...

Read More »

By Don Worthley on 10/4/2007 5:44 PM

OK, so this is a full year old, but I hadn't seen this blog entry by Andrew McAfee from Harvard Business School until now.  Arguing that the raw materials necessary for Web 2.0 were in place years before critical mass was reached, McAfee says,  

"Programmers could build fully-functional wikis, blogs, tagging systems, and prediction markets by carving them out of solid COBOL and serving them through the first Netscape browser.  They'd be clunky, but they'd work.  And I bet they'd draw users, too, because they'd tap into our desire to use technology to interact with each other, and also tap into the good stuff that emerges when we do so.  As I wrote earlier, I think of Web 2.0 as the era when technologists really woke up to this;  Enterprise 2.0 will be the era when business leaders join them."

McAfee goes on to make some really interesting comparisons between SOA and Enterprise 2.0, demonstrating in the process that SOA is just another attempt in a long line of similar attempts at reducing the complexity of enterprise integration.  McAfee's point is that SOA requires an imposed structure up front; whereas, Enterprise 2.0, which McAfee defines as the "use of freeform social software within companies," allows systems and repositories of knowledge to emerge over time. 

A couple of things are interesting to me in this blog entry.  First, SOA, which, by this point, is an extremely overloaded term, is really just an attempt at solving an age old problem using the same ideas that have been tried before only with new technologies.  And all of this is orthogonal to the new world of Enterprise 2.0.

Second, Enterprise 2.0 ,along with Web 2.0 and social media, is not about the technology, but about the current changes on the business side of the enterprise.  Business executives are starting to see, one by one, the power of stepping back and reevaluating systems and methods of governance in light of their ability to encourage emergent behavior within their organization. 

Don't get me wrong, the technology is important, and there are clearly a whole host of new technologies that have made our experiences with Web 2.0 and now Enterprise 2.0 more enjoyable; but the crux of these recent shifts in thinking is really about

• the desire for,
• the freely available means to experience 
• and the willingness of various levels of management to explore new forms of governance which foster

emergence.

Technorati tags: SOA, Enterprise 2.0, Emergence, Social Media, Web 2.0, governance del.icio.us tags: SOA, Enterprise 2.0, Emergence, Social Media, Web 2.0, governance

By Don Worthley on 10/3/2007 2:40 PM

The power of using social media within an organization is leading many executives to consider the use of social networking tools which are funded based on advertising.  When I logged in to check my Gmail account this afternoon, here's the list of ads that appeared along the right side of my screen.

So, be sure to ask a few questions about the kind of ads that will appear on your site before you dive into the adoption and use of ad supported social media.  The hidden cost to your organization could be far more than paying reasonable fees for social media software that is ad free and is branded specifically for your organization.

By Don Worthley on 10/1/2007 8:54 PM

If someone asked you to describe Web 2.0 in one word, what would it be? I'll let you know what my answer would be in a minute, but first, let's take a look at this question from a couple of perspectives. One of the things I have noticed while researching Web 2.0 software over the past few months is that many vendors have released new versions of their product during 2006 and 2007 with a new marketing bullet point proclaiming that their product-- whatever it is, but let's say it's some type of CRM--is Web 2.0 enabled. When you take a close look at the difference between their older version and the new and improved Web 2.0 version, you can see how the vendor would answer this question. In many cases their one word for Web 2.0 would be AJAX or possibly Web Services or SOA.

Read More »

By Don Worthley on 10/1/2007 8:45 PM

I've been reading a lot about the semantic web lately and have come to the conclusion that Clay Shirky is right.  Trying to adopt the semantic web in an organization would be easier than trying to boil the ocean. 

I'm interested to know what you think?

By Don Worthley on 10/1/2007 8:29 PM

Where do you stand?  Is Clay Shirky right or is semantic going to be the word which best describes Web 3.0? 

By Don Worthley on 9/30/2007 8:27 PM

If someone asked you to describe Web 2.0 in one word, what would it be?  I'll let you know what my answer would be in a minute, but first, let's take a look at this question from a couple of perspectives.

One of the things I have noticed while researching Web 2.0 software over the past few months is that many vendors have released new versions of their product during 2006 and 2007 with a new marketing bullet point proclaiming that their product-- whatever it is, but let's say it's some type of CRM--is Web 2.0 enabled.  When you take a close look at the difference between their older version and the new and improved Web 2.0 version, you can see how the vendor would answer this question.  In many cases their one word for Web 2.0 would be AJAX or possibly Web Services or SOA.

Another perspective is captured by the contributors to the Wikipedia article on the subject.  They list the following general characteristics as defining Web 2.0:

"Network as platform" — delivering (and allowing users to use) applications entirely through a browser. See also Web operating system.

Users owning the data on a site and exercising control over that data.

An architecture of participation that encourages users to add value to the application as they use it. This stands in sharp contrast to hierarchical access-control in applications, in which systems categorize users into roles with varying degrees of functionality.

A rich, interactive, user-friendly interface based on Ajax or similar frameworks.

Some social-networking aspects.

When you consider a definition like this, there are a number of words that come to mind:  participation, web operating system (I know, it's 3 words), open, social, AJAX.

Markus Angermeier did a great job a couple of years back mapping some of the more common memes related to Web 2.0

As you can see, it's tough to sum Web 2.0 up in one word, especially when the definition by the community seems to be all over the place, with some people focusing on the technologies that have enabled the wonders of Web 2.0 and other people focusing on the adjectives or verbs which capture the essence or the effect of the use of new technologies.

The interesting thing about Markus' mind map of the memes is that many of the words listed were in use long before the term Web 2.0 became popular back in 2004.  It seems as though Web 2.0 is a term that captures a point in time where the technologies, the infrastructure and the participants related to the internet reached critical mass, thereby giving rise to an explosion of creativity regarding how to use the internet as a medium for connecting and sharing knowledge.

I bring this up now, because I am hearing from a variety of industries an interest in breaking free of the confines of the old way of doing business and embracing new policies and new forms of management which facilitate, very much in the same way as we have seen with Web 2.0, an explosion of productivity and efficiency. 

It’s interesting when you consider the sociological impact of Web 2.0 on organizations of all sizes. It’s hard to say which came first, but the concept of an unconference started in 2004 with BloggerCon and has since been adopted in many industries. A current meme among association executives as tracked by the authors of We Have Always Done It That Way:  101 Things About Associations We Must Change is the concept of ungovernance.

I read people like Jeff De Cagna and I realize that a new kind of executive is in demand, one who understands that their chief responsibility is, as Jeff said recently, “the capable stewardship of sustainable business models powered by innovation.”

When I try to imagine what this might mean in the real world and when I think of what it is that drives some of the more powerful aspects of Web 2.0 such as convergence and collaboration, one word comes to mind: emergence.

When I was able to pull my head out of the sand back in January of this year (2007) and I looked around at the incredible changes taking place in both business and technology, the epiphany I had was that an paradigm shift had taken place in the areas of both business and technology, and everywhere I looked, it appeared that the fuel behind each little explosion of creativity was the desire to see and experience emergent behavior.

I’ve started reading Emergence: The Connected Lives of Ants, Brains, Cities, and Softwareby Steven Johnson, and I’ve realized that while Web 2.0 covers a broad range of changes in technology and in standards and architecture, the one underlying theme connecting all of these changes is that they make it easier for emergent behavior to thrive and to produce these amazing new levels in productivity and efficiency.

If this is true, then Web 2.0 and unconferences and ungovernance are all related in that they are all fueled by the same underlying desire to publish and produce, at an individual level, pieces of work that contribute to the greater whole. What an awesome feeling to be a part of something that transcends the limits of your own existence and allows you to produce something like Wikipedia, which has roughly 2 million articles and is currently more than 15 times the size of the next largest encyclopedia, and unlike it’s printed competitors contains content that is updated just minutes after any major event.

Regardless of which side of the great divide you find yourself (technology or business), you will benefit from asking yourself, how can I leverage the underlying desire to be connected and to contribute to meaningful projects which contribute to the greater good within my industry or organization?

How about you, what one word would you use to describe Web 2.0? Or better yet, what one word do you think will describe Web 3.0? More on that to come…

 

By Don Worthley on 8/22/2007 8:18 PM

When Fred Brooks wrote No Silver Bullet in 1986, he was convinced that the majority of complexity left in the software development process was not a result of what he called accidental complexity, the complexity that results from the way we go about solving a problem; rather, it was a result of essential complexity, complexity intrinsic to the problem domain. 

I'm not as interested in Brook's speculation regarding whether we would see a 10 fold increase in productivity over a 10 year period of time.  I honestly think we're getting close to this through the use of code generation, better design patterns and advancements in object-relational mapping (ORM).  I'm fascinated by the bifurcation of the software development process into these two discrete segments: accidental and essential complexity.

It's an exciting time to be working in the software development industry, and I think the excitement builds as we are able to more clearly separate the complexity of any project into that which is related to the business problem and that which is related to the way we go about solving the business problem.  

I heard someone say on a training video years ago about component development that you wanted to "keep things separate that should be separate and keep things together that should be together."  At first, I thought, "How simple. who wouldn't follow this principle?"  But after years of working as a developer and trainer, I realize now that this rule of separation is extremely important to the development process, and in a much larger sense to the ability to create working solutions in the enterprise.

As I think through the architecture of a solution now, I realize that my mind is sifting through the problem domain trying to identify orthogonality.  In some cases, this can be hard to identify.  One of the questions that I can ask myself is "What are the areas intrinsic to this specific problem that are intrinsic to the last 10 problems I've had to solve?" 

It is this attempt to identify orthogonality which has lead to the growing interest in things like attribute-oriented programming (@OP), ORM frameworks and software factories. 

In spite of all of the advancements in areas related to the accidental complexity of software development, we still find ourselves slogging through a jungle of process and technically oriented difficulty before we ever reach the complexity of the actual business problem.

Why is this?  In part, I think it's due to the relative age of our profession.  Yes we've been around for some 50 or 60 years, but as Steve McConnel notes in many of his books and more recently in Construx, his blog and a discussion forum of his for software engineers, we still have our work cut out for us when it comes to solving problems like our engineering counterparts in other industries. 

While wonderful advancements have been made in our industry, we still fall short--in part, because of the overabundance of competing approaches to solving this problem.  I was having lunch with another software developer in the area who was describing the frustration the developers felt in their shop when they had to support a solution with a middle tier generated by LLBLGenPro.  Although I haven't used this particular ORM tool, I've heard great things about it.  The issue was that most of the developers on the team didn't have experience with this ORM either.  They've probably had experience with other ORM tools, but unfortunately the infrastructure of each ORM tools is different.  Take .netTiers, for example, which--although, like LLBLGenPro, generates the classes based on your data model-- does not use the same templating engine.  .netTiers uses CodeSmith, which is a great code generation tool, but has its own learning curve.  Or take NHibernate, or Hibernate if you're a Java developer (I realize Hibernate came first, but I'm a hopeless .NET developer).  With NHibernate, you develop the description of the domain model and the tool generates the data model to support your domain objects, kind of the reverse of .netTiers and LLBLGenPro.

Even Microsoft has jumped on board the ORM wagon with LINQ and LINQ to SQL.  As you may have seen in previous posts, I have grown fond of SubSonic, a very simple, easy-to-use and open source ORM.

But the issue of orthogonality isn't just about ORM tools.  As I mentioned above, attribute-oriented programming techniques have helped tremendously in the effort of dividing the technical and business related domains.  In fact, attribute-oriented programming probably should have been called orthogonality-oriented programming, but OOP was already taken.  The whole goal with attribute-oriented programming is to identify those aspects of business solutions that are orthogonal to the business logic, aspects that occur in almost every business application written, aspects such as logging, wrapping operations in a transaction or enforcing some form of authorization.  You can see this in action with the Enterprise Services features built into the .NET framework. 

Additionally, the recent interest in Service-Oriented Architecture (SOA) has lead to wonderful improvements, on the technical side, in how business process are properly organized and made available to disparate solutions within an organization.  At the heart of these improvements is the desire to identify the proper kind of separate between business logic and the technical aspects of how that business logic is organized and made accessible.  Over the years, we have found that further dividing our business logic into orthogonal services that are accessed with clearly defined and immutable contracts makes it easier to reduce the duplication of effort that had become so common in enterprise development.

So how is all of this important to me on the business side?  It's critical in today's market to be identifying solutions that have implemented a high degree of orthogonality between the technical and business domains as well as between different technical areas that need to be properly separated.  Hire an independent consultant or have your in-house architects take a look at the infrastructure of any proposed solutions within your organization in light of this issue of orthogonality and ask questions about how the proposed solution makes use of current best practices to keep things separate the should be separate and keep things together that should be together.  The solution doesn't have to use an ORM or to even be programmed in an environment that makes use of attribute-oriented programming or SOA, but it does need to be extensible and maintainable, two areas that suffer the most when an application is not designed well. 

Here are some issues I would consider when thinking about the orthogonality of a proposed solution:

• What tools, frameworks or factories have been used in the development of the solution? 
• Are they proprietary or open source? 
• If they are proprietary, how widely has this platform been adopted in the industry?  What kind of documentation is available and how active are the support forums?
• If they are open source, how widely is the open source project adopted and how active is the community?
• Has the vendor re-invented the wheel in solving common technical infrastructure issues?  For example, have they written their own workflow engine when they could have used an existing workflow framework?
• How has the business logic been organized internally and what are the APIs for accessing that logic.  Are they using industry standards or principles such as SOA? 
• If the solution provides access through web services, how have the web services been developed?  How is authentication handled?
• What design patterns were used in the development of the software?  For example, does the solution use MVP or MVC to keep business logic separate from the UI?
• How have the extensibility layers been developed? 
• Have best practices been used to help ensure that extending the product won't cause issues with upgrades to the baseline product?

Recently, I've spent some time looking at Microsoft Dynamics CRM 3.0, and, although I haven't had the chance to write an application on top of this framework, I've been very impressed with what I've seen, especially related to the orthogonality of the business and technical domains.  While there are some limitations such as the inability to natively handle many-to-many relationships between entities, a limitation that I hear will be addressed in the next release of CRM code-named Titan, the framework seems to provide a way to begin focusing on the business domain without spending an inordinate amount of time writing your own infrastructure.  The extensibility points are there, and they have been designed so that upgrades to the baseline product should have minimal to no effect on customizations.

How about you?  What software have you used in your organization that has maintained a high degree of orthogonality between business and technology? I’m interested to hear from you!

By Don Worthley on 8/8/2007 8:15 PM

WARNING:  This is a technical entry with no business related information.  It relates to Microsoft SQL Server, SubSonic and .NET with code written in C#.

I was responding to an issue in the SubSonic forums a few weeks back when I discovered that the INFORMATION_SCHEMA.PARAMETERS view didn't contain information on the nullability of a stored procedure's parameters.  No problem, I did a little searching and found the following two stored procedures: sp_sproc_columns and sp_procedure_params_rowset.  Excited at the promise of valuable information on the nullability of my parameters, I ran the following script to create a quick stored procedure that contained both a parameter with a default and one without.

CREATE PROC TestProc (@intDefault int = 0, @intNoDefault int)
AS
SELECT @intDefault as 'ValueEntered'

I ran both of the stored procedures above only to find that the nullability for both parameters was the same:  nullable.  Hmm.  Ok.  I must be misunderstanding what it means for a parameter to be nullable.  At this point, I began to see that I had confused having a default value, which determines if having at least some value (maybe NULL) is required, and being nullable.  So I dug into SQL Books Online and found that