The S Curve

Semantic Wikis in the Enterprise - Sanjiva Nath

Semantic Wikis in the Enterprise - Sanjiva Nath

Shared via AddThis

zAgile @ '09 Semantic Technology Conference

This year's Sem Tech brings exciting opportunities for us.  I will be participating in two sessions. 

1. Semantic Wikis -- which includes participants from Vulcan, SRI, ontoprise, University of Karlsruhe and Stanford University

2. Semantic Framework for Model Driven Process Deployment and eXtreme Traceability -- a presentation that I will share with Dan Pattyn who will provide real-world use cases for eXtreme Traceability towards which our proposed solutions are most applicable.

The Sem Tech topic list this year continues to be very exciting and demonstrative of the rapid evolution and mainstream adoption of the technology.  

Can't wait for Sunday.

@ Reiter's Books in Washington DC

The ladies at Reiter's Books are quite gracious in cohosting meetups, such as the Washington DC Semantic Web meetup.  It was here last Thursday that zAgile had the privilege of presenting its vision related to semantic technologies to an audience of over 30 people.  The attendees were fairly diverse but there was a lot of obvious representation from those in the government or representing its interests.  I met people from DoD, Agriculture, Library of Congress, Project10X (Mills Davis), etc.  Brian Eubanks organizes these events in DC along with Marco Neumann, who came from New York to attend this session.   The session was quite interesting and it was great to see the work that guys at Knoodl presented.  Knoodl's platform allows for the collaborative development of OWL/RDF based ontologies and knowledgebases.   Sharing ideas related to a common set of technologies with people who are exploring from a fairly wide range of interests is quite exciting.  It is also great to see the domains in which semantic technologies are now being applied for commercial applications.

-Sanjiva 

A semantic web gathering in Cambridge

These are exciting times for semantic web technologies, as they gain inroads into commercial enterprises.  Semantic web meetups are springing up in cities across the US and Europe with a lot of exciting topics, demos and discussions.  With Marco Neumann's guidance, zAgile has committed the month of April for a very special roadshow covering eight cities across the US beginning with San Francisco and Palo Alto.  

So on Tuesday last week, it was the Cambridge Semantic Web meetup (Strata Center, MIT) moderated by Susie Stephens (Eli Lilly) and Kingley Idehen (OpenLink Software).  It was exciting for us to have the privilege of being able to share our implementation vision of semantic web with so many influencers in this field but even more so because of the presence in the audience of Tim Berners-Lee.  Tim has been driving a lot of interest and thought into this field for over a decade and to see him still actively involved in organizing and attending such gatherings is very exciting.

It is also interesting to observe that while offering diverse representations, each meetup still has a different makeup in terms of representation and interest.    The Cambridge meetup was a mix of academic researchers, W3C, sem-tech companies and Pharma.  A lot of the focus seemed to be on theoretical aspects of semantic web technologies.

I enjoyed the energy and interest level of the gathering and it was well worth the trip for us.  After the session, the group moved on to the bar next door for cocktails and more fun dialogs that continued late into the night.

-Sanjiva

Strata Center, MIT

  

4 Reasons Why Enterprise Wikis Fail Adoption

While offering an easy-to-use collaborative platform for teams to capture and share knowledge about their products, processes, people and projects, enterprise wikis also typically have limitations that have often impeded their wider adoption and usage in the enterprise.  Here are 4 key reasons why I believe they often fail to deliver value. 

1. Accessibility - You do not have rapid access to precise information.  Unless everyone has awareness of the page-hierarchy and the overall content organization scheme, information isn't so readily or intuitively accessible.  Wildcard searches maybe the only mechanism for others to find information.  If there are multiple wikis (which isn't uncommon) then it becomes even more difficult.  They become siloed information stores.

2. Reliability - Content is static and has a tendency to become stale (thus unreliable).  Since information or content is primarily user-generated, it tends to be static in nature.  Unless someone is taking the responsibility for diligently maintaining this content, it becomes stale and unreliable very quickly. 

3. Maintainability - Content is unstructured and thus requires a great deal of manual effort and discipline to keep it current.  Cross linking of information across pages typically involves copying and pasting URLs.  Integration with content outside of the wiki is also the same process.   

4. Integration - Most wikis are supporting mechanisms for integrating widgets into the content - which provides for some limited way of bringing data from other applications.  It is not quite the same as integrating information, since it is rarely contextual. 

zAgile's Wikidsmart addresses all of the above and more.  Easy to create and use templates provide a mechanism for creating and maintaining content.  The templates also allow for a way to capture attributes on a page that facilitate automatic and contextual cross-linking and referencing of information across the pages and across wikis.  Through its interface with zCALM (zAgile's Knowedge Server), Wikidsmart can also integrate information from any other application.  It turns the wiki into an Information Portal. 

Wikidsmart is currently available for Atlassian's Confluence Enterprise Wiki.  Through upcoming connectors for Atlassian's JIRA, Subversion and CruiseControl, it provides very powerful capability for integrating Software Engineering Projects with Requirements, Test Cases, Tasks, Checkins and Build activities.   It can similarly be applied to integrations across applications in other domains.

-Sanjiva, Orinda

zAgile @ SF Semantic Web Meetup

Last Thursday night, we (zAgile) hosted the second meetup of the fast growing SF Semantic Web community.  The topic was "Practical Semantic Web Applications for Your Organization".  We presented our technology (zCALM) and product (Wikidsmart) as examples of information and application integration using semantic technologies.  

Atlassian was very gracious in providing the venue for the event.  And of course, the demo of Wikidsmart for Confluence provided a showcase for the seamless integration of Atlassian's Confluence and JIRA that can be achieved using semantic frameworks.

 It is great to see so much growing interest on this topic from a variety of domains and disciplines.  Attendees represented a fair mix of early explorers of the technology and those actively focused on developing ontologies for specific domains.   Andrew did a great job of organizing the event, presentation session as well as networking.  Circolo was the post-event networking venue.  This group had a lot of exciting energy and passion for these technologies.

Sanjiva, Orinda     

Semantic Technologies within Enterprise Data Management

Today, I had the opportunity to be on the panel at Enterprise Data World to discuss the role of semantic technologies in enterprise data management.  The panel followed a working session consisting of roundtable discussions exploring a number of specific topics related to this theme.  All-in-all, a very interesting and revealing set of discussions.

The two most revealing points that stuck were:

1. There is significant confusion between semantic technologies and semantic web.  In some respect, this is a bit embarrassing for the community that is trying to define semantics of other things.  The consensus was that we need to keep the two separate and define each clearly.  The challenges and solutions are not the same between the two.  I mostly agree with this.

2. Semantic technologies seem to threaten the status quo in the enterprise data community -- in much the same way as object-oriented programming did to the C-development community in the late 80's (so it seemed to me, anyway).  I didn't see this coming.  "we can model anything using our current techniques and technologies -- so why do we need semantic xxx".   The reluctance to adopt this recently popularized technology (I won't call it new) was quite significant. 

I thought it was important to note some of the thoughts that came out of this group (without any perspectives, endorsements or editorials):

Semantic technologies-

1. do the same job as data modeling but better/faster.

2. add web-centric web aspect to the table-centric world of relational databases.  Are easily extensible (rather than expanding tables after tables)

3. Ontologies provide significant flexibility in modeling

4. means that a term is defined by its relationship to other concepts instead of text paragraphs

5. and definitions can capture logical discrepancies

6. provide for more precisely defined taxonomic terms

We will try to take these discussions and perspectives to Semantic Technology conference in June.  It will be interesting to see how these perspectives evolve in the near-term.

-Sanjiva, Tampa, April 8, 2009   

Semantic Enablement of Wikis for Enterprise Information Integration

Yesterday, I gave a "lightning talk" (3 min prezo) at SemanticWiki mini-series Session-2 hosted by Ontolog.  It was interesting to hear the evolution of semantic wikis to date and the varied focus and unique applications offered by various organizations.  Its even more interesting that with all that these wikis promise, they have not picked up much attention in an enterprise.

Here is the rough text that accompanied my presentation:

Our focus at zAgile is towards information integration within the enterprise -- towards which, the wiki is only one of many potential sources of information or knowledge.  Rather than treat the wiki as THE knowledge repository, we have developed technology and extensions which allow the wiki (as well as other applications) to contribute to a central information repository, although the wiki may also functions as a 'portal' or 'dashboard' for integrated information.  In this regard, we have focused on "semantically enabling" commercially deployed wikis such as Atlassian's Confluence. 

 

The semantic enablement consists of three major components:

1. Within the wiki -- it is Templates, Forms and Query support. 
   1. Templates are based on pre-defined ontologies, each one potentially representing a single concept, its attributes and relations, such as Artifact, Person, Task, etc.  Templates support pre-population of instance-specific data from the repository via embedded SPARQL queries
   2. Forms are based on templates, to allow users to create hybrid pages -- consisting of semantically structured as well as free-form content -- in an implementation similar to the work done for MediaWiki.
   3. And of course, you can write SPARQL/RDQL type queries and integrate and enrich wiki content with information from external sources.     
2. zAgile's ontology-based repository consisting of domain-specific ontologies (our current focus is on ontologies for software engineering)
3. zAgile's semantic framework which provides a consistent mechanism for all applications, including wikis to interact with the repository

 

The central ontology-based repository provides for unification of information across the enterprise, incorporating what so far has been relatively "unstructured content" that lives in the wikis and offers little contextual value. 

 

-Sanjiva, Prague, Nov '08

Information and Knowledge Integration in an Enterprise

 Recently I came across an article by Ricardo Falbo, et al. from UFES (Brazil) that identifies various dimensions of information and knowledge integration that I wanted to share.  These are:

 

• Data Integration
• Presentation Integration (enterprise portals and mashups)
• Control Integration (what we often think of as application integration)
• Process Integration (see my earlier blog on this)
• Platform Integration
• Knowledge Integration (emphasizing knowledge capture through rich semantic definitions)

 

The context of the discussion is ODE (Ontology-based Software Development Environment), developed at UFES, but it is quite applicable to the needs of any enterprise and not just Software Engineering.  Also, while most enterprise solutions focus primarily on data integration or application integration, none consider all these in a single composite offering.  In that regard, through the application of semantic technologies (particularly a rich set of ontologies), ODE is one of the first systems that I have seen which demonstrates how one could offer such a complete and seamless integration.  While ODE attempts to do this via a full blown application, I believe that soon we will be able to achieve this level of integration across heterogeneous applications in an enterprise by combining some of the recently evolving technologies, including those related to the semantic web.  An example of one of these was recently mentioned in Bob Zureks' blog   

 

Sanjiva, Orinda, Nov '08.  

Process Integration in Software Engineering Environments

If you ask someone in software engineering about their processes, you are likely to get some combination of the following responses:

• A slideshow walkthru of their release cycles and processes
• A rundown of tools implemented by various teams
• A repository of various artifacts generated through their delivery cycle that may reflect execution of the process steps

 

In other words, hints of an organization or team's processes typically exist in some combination of Powerpoint slides, collection of tools and evidence of process-related artifacts but not quite integrated into the environment itself.

 

The degree of details or comprehensiveness of the information you will encounter will depend a lot on the organization's process discipline and maturity. 

 

The problem here is that these responses do not totally reflect what is really happening.  At best, it reflects the intent of the process implementers (usually engineering managers) and generally a high level articulation of that intent.  So you would either take their word for it or conduct a more thorough due diligence which would be an elaborate set of interviews, reviews of artifacts, delivery plans, etc.   That is, if you are an outsider.  If you are the one who has just joined the team, then the process learning is in itself an ongoing process.  You will learn the processes mostly by getting involved with the team(s) through various exercises of maintenance cycles, patch fixes, release deliveries, and so on.  In other words, there is a ramp up period for you which could easily take several weeks or months -- just to learn how to perform your tasks within the context of the team's process culture.  

 

It is no wonder that teams are so often out of sync with respect to their processes.   This is particularly an acute problem when teams are distributed.  When outsourcing or offshoring, most teams do not even bother to align their processes.  Teams adopt their own local process cultures.

 

As one would expect, this is a key contributor to high failure rates in software projects with offshore or distributed teams.

 

This problem exists because software engineering process definition, its integration into the lifecycle and tracking (for exceptions and compliance) -- are manually intensive and tedious.  Diligent and disciplined managers are able to maintain some level of efficiencies with small local teams but their efforts quickly become unwieldy and impractical when the team size grows beyond 10-15, and when they introduce offshore teams into the mix.

 

Tool vendors do not tackle this problem because they are focused on their tools being adaptable across processes and methodologies.  They do not care about what process you choose, nor do they impose one.  They simply want you to be able to use their tools.

 

ALM vendors take a step forward by offering you an integrated environment that is committed to a certain methodology.  Whatever the latest trends may be, you can find a vendor with an integrated environment that reflects a reasonable integrated representation of a lifecycle of that trend.  Here, you have to commit to their methodology and their environment.  You cannot mix paradigms.

 

So what do you do for your own environment?  If you have chosen best of breed tools for your teams, and have implemented processes and methodologies that most closely reflect your business needs, teams' cultures and abilities -- how then do you effectively capture these processes and methodologies in sufficient details, reuse them, modify them, disseminate them to your teams, reduce their ramp up cycles, enact methodologies for specific projects, automatically have your tools configured to represent the processes, and track the process execution through a project lifecycle? 

 

How indeed!!

 

Well, now there is a way  :)  

 

http://www.zagile.com/introductiontozcomposer.html

 

 

-Sanjiva, Orinda, Nov, '08.

In software outsourcing -- time zones matter

Companies engaging in software outsourcing/offshoring, or that have distributed software engineering teams, tackle a variety of challenges related to the distributed aspects of their operation.  Through some combination of collaboration tools, technologies, processes, T&E $s, lots of late night conference calls, etc., they work towards managing through these challenges and experience varying degrees of success with their projects.  And they do that while striving to reduce overall engineering costs (the key objective for most of them). 

 

Of the challenges they face in coordinating software engineering projects across distributed environments (and there are many), I believe that time zone difference is the most significant. You can save money, find great talent and implement the most effective platform and process for collaboration and software development -- but not being able to reach people when you need to still makes a difference in the 'velocity' and effectiveness of your development/delivery lifecycle.

 

While this was not the key factor influencing our decision to establish teams in South America, we certainly have benefited tremendously from it.  With teams in Chile, Peru and Brazil, our teams (or individuals) have never been more than six time zones away.  This means that throughout the year, there is always a core window available for us to collaborate.  Of course, this does not mean that we are in constant hourly contact.  In fact, I spend an average of an hour a day on such communication.  It simply means that people are more accessible and therefore there are more opportunities for direct (or synchronous) communication, brainstorming, etc.

 

While most people address this issue through a lot of after hour calls as well as relying on local management teams, we have had to do neither.  Having to hire offshore management team to look over local operations obviously adds to the overall costs.  We have hired and managed individuals directly, maintained a flat team structure, regular work hours, and implemented a number of different agile techniques towards the development of our platform and solutions.  Given that we are implementing leading-edge technologies, the model has worked very effectively for us -- both in the development of our products but also during deployment with our first customer.

 

All this without compromising on the cost benefit or talent.  In our case, we have a significant edge on both fronts. 

 

So time zones matter.

 

-Sanjiva, Oct 2008

Making Minimum Ontological Commitments

In my last blog, I cited some examples of inconsistent semantics that are prevalent in applications as well as in their usability. Applications tend to be siloed in nature and their schema often corresponds more tightly to specific dialects. The end users make it worse by often using it for multiple purposes, thereby muddying the semantics even more. Also as I mentioned in the blog, this becomes a nightmare for those striving for an Information Integration strategy (a cohesive platform that unifies information across tools, departments and processes). Such strategies and solutions have been championed by some of the biggest vendors in the applications and infrastructure space (IBM, SAP, Oracle) -- via their MDM (Master Data Management) or EIM (Enterprise Information Management) strategies. 

But how does one effectively address this EIM challenge? 

To us, the answer is relatively simple. By making "minimum ontological commitments". Of course the devil is in the implementation details. 

• First of all, it involves a set of interconnected ontologies (or sub-ontologies) which together provide a specification for a domain (in our case, Software Engineering). Examples of these sub-ontologies would be SCM, Process, Person, Document, Test, Requirement, Collaboration, etc. These ontologies provide a consistent and coherent vocabulary that can be shared amongst applications, processes and people within a domain [Gruber]. The focus here is on consistent sharable vocabulary and not necessarily a mechanical mapping of schemas across applications. Each application may still have its own dialect that is not relevant beyond its sub domain -- therefore the emphasis on making minimum ontological commitments.
• Second, an infrastructure that maps and captures this semantically relevant information from each application (or tool) into the semantic repository (aka Information Integration Framework).
• Third, semantically enabling the applications and the overall platform so that the same information is accessible to all participants and agents using the same vocabulary and taking it a notch higher -- creating composite views or dashboards from this integrated information to alter the traditional metaphors of how we see things.
• Fourth, leverage reasoning capabilities from the ontological specifications to get beyond the data that is empirically captured and enrich the knowledge base.

  So it is quite straightforward :)

 

    In concrete terms, such commitments can answer simple questions, such as:

Who broke the build, what tests were conducted for a particular set of checkins, who reviewed them, what requirements or bugs initiated the actions, who authorized the final move to production of a particular set of changes, what customers are impacted, which components are most vulnerable with respect to defect density at a particular development stage, etc. 

  Of course, we can get these answers now but it either requires a lot of walking the hallways and late night phone conversations with remote teams to gather the information across teams and silos, or making some costly commitment to an integrated toolset from one particular vendor.

   

  Or, the questions above can be more directly and easily (and automatically) answered in your own environment with your own processes and tools -- by integrating the zAgile semantic infrastructure.

  Its about Information Integration in your world.

   

  Its about building relevant knowledge through this integration that will allow you to effectively collaborate, coordinate and manage your software development and delivery cycles.

-Sanjiva, Orinda, Oct '08

The value of semantics in applications

Commercial software applications often tend to be quite loose and non-binding of any conventional semantics when it comes to implementation of their metamodels.  This not only impairs their usability but also has significant impact to their ability to integrate with other applications and systems in an environment. 

   

A case in point -- Atlassian's Jira issue management application -- which has become quite popular with organizations of all sizes as well as a number of open source communities.  With over 10,000 customers for its products, it is no wonder that we (zAgile) have been taking a closer look at the Atlassian application suite with respect to integrating them into our semantic framework for our customers.   

   

One of the most curious aspects of Jira that has often perplexed potential adopters is its metamodel.  We see people often confused with some of its key concepts or use them  arbitrarily thus potentially contributing to a different set of usability problems.         

 

Most notably in this context is the Jira 'Project'.  This defies any coherence with the common or conventional notions of a Project.  For starters, people tend to associate projects with a begin and end date.  Not so in Jira.  Projects go on forever with interim deliveries packaged as releases.  So what is a Jira project and how do you plan one? 

   

Then there is Component.  It seemed intuitive at first since semantics of the word 'component' are also not too controversial--that is until you begin to see how people have applied it in practice in Jira.   

To understand the usages of some of these fields, you can look at Atlassian's JIRA site.  Another popular Jira site for us has been JBoss.

   

In both usage models, the concept of Project more closely resembles a software product or component (example -- Jboss Enterprise Platform, JEMS, Jboss Shotoku, Bamboo, Clover, JIRA, etc).  There is no hierarchy or crossover relationship between software components so the issues or tasks within each have to be fairly isolated from those belonging to another Project.  Of course, there are Project Categories (example: Atlassian Products, JIRA Plugins, etc) -- to help organize the Projects.  But how do those fit into our mental model of Projects? 

   

Similarly, I have seen examples of Components such as QA, Performance, Test Suite and Documentation.  Its tough to figure out the definition (or semantics) of Component from such usage. 

 

And finally, if we are going to be arbitrary in terms of how we use these fields, then how do we integrate them with similar concepts in other tools?   Is a Jira Project the same as an MS Project instance?  Are all values in Component representing software components? 

      

This emphasizes the value of common and shared semantics in applications that would facilitate both usability and potentially integration.  While Jira has a lot of third-party support to make it functionally rich, a lot of people are still spending significant amount of effort towards integrating it with other applications and processes within their environment.  And many of them are struggling with the lack of consistent and coherent semantics.

      

   -Sanjiva, Orinda, October '08

Confluence is now Wiki'd Sem'art ... and it SPARQLs

Of course, there is a lot of pun intended here.  We (zAgile) recently added semantic capabilities to Atlassian's Confluence wiki and are quite excited about its impact to a very popular yet traditional wiki.

In my earlier blogs, I had been talking about my quest for semantic wikis.  Wikis provide an easy way for teams to produce and organize content--creating very effective central repositories, often used for cross-departmental collaboration and information exchange.  The problems arise when all this statically organized content becomes unwieldy in terms of maintenance, and more importantly access.  You end up spending lots of time in wildcard searches across all this content, repetitively navigating complex hierarchical page structures and constantly maintaining links across wiki pages to keep the content credible and current.

 

Semantic capabilities make wikis a dynamic application.  Addressing the problems noted above, they allow for content to be 'semantically' annotated with the annotations stored in  semantic repositories, therefore, the meaning is captured in a machine-processable way and is more directly searchable, shareable and accessible across applications not just from within the wiki itself.

 

To 'semantically' enable Confluence, we have taken the following steps:

1. Provided support for SPARQL in Confluence.  Analogous to SQL, you can embed SPARQL queries anywhere in a page and the data may be retrieved from semantic repositories anywhere on the web.  This allows for auto integration/incorporation of data from external systems into the wiki.  These queries can also provide a mechanism for dynamically organizing more readily addressable wiki content. 

2. Provide Semantic Forms in the wiki which allow users to create 'structured' or semantically annotated content.  The data and object attributes associated with a page created using such a form are captured in the semantic repository while the page maintains a composite of both semantic and unstructured content.  We have used such forms to create Feature/Requirements Documents on a wiki page.  Since the page is annotated using Requirements ontology, this provides a very effective approach to link requirements to projects, tasks, bugs, test cases, etc. in a software engineering lifecycle -- all data that exists in tools external to the wiki. 

3. Provide macros that allow users to annotate any existing page on a wiki based on the available set of ontologies (Project, Person, Document, Process, etc.).  Again, semantic annotations provide a deeper and more structured mechanism than just metadata tags for capturing relevant information from each page and organizing it within the wiki in a more meaningful way as well as integrating it with external applications.

                                          

And lastly, this semantic capability can now be added to any extensible wiki -- to make it wiki'd semart and sparql'ing :)

                                                

-Sanjiva, Orinda, October '08

Learning from Rachel Dawes

"But it's not who you are underneath, it's what you do that defines you"  -- Rachel Dawes in Batman Begins      

         

This catchy quote from Batman Begins had me a bit puzzled when I first saw the movie.  What does she mean by that, I thought?  But it stuck.  If you have seen the movie, you will understand why.      

                  

And then in a totally different context, while trying to submit zAgile to various search engines and business directories, it became somewhat clearer.  The problem I encountered had to do with figuring out where to categorize zAgile.  Yahoo's taxonomy seemed pretty dated and perhaps severely constraining.  It shouldn't be so difficult, I thought.  But it was.  Why do I have to fit zAgile into some pre-defined category?  Why can't I just say 'what it does' and have 'what it is' inferred?  The problem with Categories is that an individual may belong to more than one category and the categorizations are not necessarily permanent.  Categories definitely cannot be used to define what something 'is'. 

          

So it seems that we are constantly constraining ourselves by putting 'things' into specific categories.  When you have to put a book on a shelf in a library then obviously you need to make some hard choices.  But in life, what something 'is' ought to be defined (and inferred) based on its attributes and relations to other things.   

                            

In a somewhat obtuse, indirect and 'Heideggerian' sort-of way, maybe Rachel was trying to say the same thing.  Her quote curiously made me realize the key difference between taxonomy and ontology.  We are so used to dealing with taxonomies when developing applications that the power and flexibility of ontologies are difficult to grasp and leverage.  While ontologies often take the form of taxonomic class hierarchies, they are not constrained by them.  Therefore, rather than struggle with categorizing something, we use an ontology to define it using its characteristics (or attributes) and relationships to other things.  And all that it 'IS' is simply inferred.      

      

And that is all what Rachel was trying to tell Bruce Wayne (so I believe, anyway).         

         

-Sanjiva

'If Onlies' of Application Lifecycle Management

In a recent blog, Carey Schwaber (Forrester's Senior Analyst focused on Application Lifecycle Management) points out some of the unconquerable hurdles that we face in software engineering -- the perennial 'If Onlies':

• If only requirements were complete
• If only there were enough time to test at the end of the life cycle
• If only everyone followed the process
• If only development efforts were predictable
• If only metrics were comparable across projects
• If only our tools worked together
• If only we weren’t constrained by legacy
• If only we could reuse our prior work
• If only software were easier to evolve

It is easy to resonate with this list.  Almost every organization faces these challenges.  It is also easy to add so much more of 'if onlies' to this list from our experiences. 

There is also another dimension of 'if onlies' with which we struggle the most -- a dimension that involves visibility, i.e. 'If only we know'.  For emphasis, I will map each one of these to Carey's list above.  In my experience, lack of visibility has been the key source of problems that we encounter (and she exposes) in Application Lifecycle Management. 

 

If only we know...

• whether requirements are complete, when they are complete, when they changed and why they changed.  Product Managers, Business Analysts, End Users -- all play a key role in the definitions but most of the time we are building software to meet the changing needs of a business or customer(s).  While the delivery cycles need to be rapid to allow the business to stay competitive, what's explicitly needed isn't either always clear or it is changing rapidly.  Not to mention the fact that we don't always know how much we need to know until we get into the delivery cycle. 

• what will be tested, how will it be tested and how will it allow us to measure product quality.  When requirements aren't well known or are fairly dynamic throughout the delivery cycle, QA often resorts to ad-hoc testing.  There is no way to know when 'that' cycle could be completed.  Good QA teams are able to plan very precise execution of test plans and test cases that map to known product features/requirements.  And if they are efficient and creative, they can even automate some of this -- but this level of execution is practically seen mostly in maintenance cycles -- and rarely in new product or feature development.  Therefore, not only do we not know how much testing is needed, we often do not know what specifically is being tested.  This becomes more critical in large organizations that need to connect these dots to address their stringent auditing, compliance and traceability needs.

• how to effectively capture, disseminate and track the methodologies and processes the teams are using.  This is a difficult one but when you have distributed teams (offshore, outsourced, remote etc.) -- most managers struggle with establishing or controlling specific process that are being followed by their distributed teams.  For starters, there isn't an easy way of capuring or tracking an organization's methodologies or processes.  Any suggestions of a process or methodology typically exists in Powerpoint slides, Word docs or wikis but does that mean it is being executed with precision.  Since process tracking is manual, it relies on a lot of walking-the-hallways or 6am phone calls to India (or Ukraine or …) to track.  Add to this the complexity of disparate tools used by different teams and it becomes very difficult to follow the process. 
• how to leverage an organization's best practices towards future projects, how to tie them across teams and how to evolve processes and methodologies through effective post-mortems -- all in an effort to improve overall predictability of delivery. 
• what and how to report with respect to project progress and how to get that information. We often do not have control of what we are trying to track mostly because the information available to us is so limited.  What do we track -- the process or project status or quality or completion or compliance or …?  This gets crazier when you have teams in different geographies with different processes and qualitative metrics used in their reporting. 

• how to integrate information across teams and tools.  Every team manager excels at hand-picking tools and implementing processes that are effective for their teams.  But he or she is not able to incorporate those across other teams.  And breakdowns in ALM most often occur during hand-offs.  Managers take solace in knowing that their teams performed effectively when 'inputs' were predictable and controlled, yet because of their 'siloed' mentality, they fail to coordinate and deliver towards the overall success of the project. 

• how to effectively capture knowledge needed to deal with 'legacy' software.  Legacy here doesn't necessarily refer to stuff developed in the 60's.  If an organization radically shifts its technology and architecture between releases then even software developed in the previous release can quickly acquire the 'legacy' status.  If likely it was developed using RAD and Agile techniques, perhaps not enough was captured to describe the functional or technical feature set. 
• how to create a knowledge source that integrates 'what' was delivered with the 'how' and 'why' -- to allow teams to leverage that knowledge and 'reuse' previous practices towards future work.  This is critical when you have offshore teams involved that have annual attrition rates of 20-30%.  If a third of your team disappears each year, they aren't likely to know what was done before and therefore how best to 'reuse' it.

• any relevant strategic direction of the product or technology (coming back to the overall goal or vision of the organization and project) at the level of those involved in the trenches -- to control any evolution of the product or service.  Well crafted and planned iterations allow for controlled evolution but the overall lack of visibility into the big picture still takes away from the overall effectiveness.

                                     

Of course, this isn't just about adding to the problem set (to address 'The So What').  There are 'alternate' 'transports' (using Carey's metaphor) to address even these 'if onlies'.  zAgile's Solutions provide the 'game changing tactics' by addressing each one of them.  In this blog, I wanted to provide some of the things that we have attempted to tackle with our approach to Intelligent Application Lifecycle Management. In subsequent blogs, I will provide details on how a software engineering organization may apply zAgile's Solutions to address these chronic pains.

                                                

-Sanjiva

A Practicum in Entrepreneurship -- A lecture at Prague University of Economics

Ealier this month I had the opportunity to address the students of Cognitive Informatics at Prague University of Economics to discuss my experiences and perspectives on transforming a creative idea into business.  The lecture was organized by Professor Vaclav Repa.  With zAgile serving as the example model for the presentation and discussion, it was an interesting opportunity to talk about how the idea was conceived and all the steps that we have gone through with respect to early research, concept validation, product development, market analysis, category definition, etc., as well as the challenges that lie ahead of us.   This was my third presentation to an academic audience  (the first two in South America to students at Pontificia Universidad Católica in Chile and UFES - Universidade Federal do Espírito Santo in Brazil).  A shift from the previous presentations, the interest in this particular session was primarily the business (revenue model, marketing strategies, etc) aspects of enterprise incubation rather than the technology behind the vision.  I enjoyed sharing our vision and progress with the students and also gave them a product demo (a sneak preview of sorts).   

 

On The Power of Semantic Wikis

While the popularity of wikis in the corporate world continues to grow due to the ease with which they allow anyone to publish web-based, shareable and easily accessible content, they also have a number of serious limitations which have been difficult to overcome mostly due to the inherent design.  The most significant of these are:   

                                             

1.     Hierarchical structure of pages -- unless you maintain multiple hierarchical relationships (or references) of your pages, you have to always remember where a specific page content (or topic) may exist.  Not only that but the consumers of this content must also always be aware of the structure or taxonomy.  In the absence of this, endless navigation through the trees or wildcard searches are the only other way to find what you (or they) seek.  In the corporate environment, people seldom have the time or opportunity to construct such taxonomies unless it is a dedicated activity or the wiki package comes with some pre-defined and ready-to-use templates. 

2.     Content updates -- Once a wiki grows to hundreds or thousands of pages, it is much more difficult to find content and keep it up-to-date since it is a manual process.  However, if you can't keep it current then the repository loses its credibility and the wikis quickly become shelf-ware.

3.     Contextual relevance -- While people create content on the wikis at will, its organization and hierarchy are often pretty arbitrary.  Furthermore, there may or may not be a context associated with the content, or perhaps if there is one, it is implied by the author.  So you end up with lots of content without any seemingly contextual relevance.  Once again, something that becomes difficult to maintain and leverage over time.

      

With all the right spirit of generating and organizing a lot of content with ease, I have seen wikis become cumbersome, unwieldy and useless fairly quickly.   

   

With this in mind, I envisioned (and began researching two years ago) the idea behind wikis that could support semantic annotations, thereby adding some needed structure to a naturally unstructured content store.  Semantic annotations, I believed, would allow content to become much more self-organized, accessible using contextual searches and queries and updatable using software agents (where relevant) -- all adding up to some powerful capabilities.   

                

I found a number of projects exploring this concept during this time.  I think the closest one to the vision that I had and the one that we at zAgile have chosen to leverage in our platform -- is the result of efforts by Zdenko (Denny) Vrandečić  & the team at Institute AIFB, Universität Karlsruhe, in the form of an extension to MediaWiki called Semantic MediaWiki (or SMW).  We believe it to be a very efficient implementation of semantic technology on top of a wiki engine.

 

Supporting a very popular wiki (the engine behind Wikipedia), this extension allows the user to create annotations to any page in a free-form manner.   It’s the easiest and most user-friendly approach to creating some structure to a vastly unstructured pool of content.  Once annotated, pages can now be organized in any way using templates and queries and the content of any or all of these pages can easily be reflected elsewhere through simple semantic queries, rearranged, summarized, tabulated, accessed by external applications, etc. etc.  The idea is not much different from the queries and result sets that we are used to getting from relational tables.  However, the depth and expressivity of semantic annotations goes beyond what we are normally able to express in relational models (of course!! another topic) and the interfacing with external applications (both in and out; using RDF exports) is much easier.    

                     

This capability, in my opinion, makes the wiki a very dynamic and valuable application.   

             

For our purpose, we have taken this base foundation of MediaWiki + SMW and extended it in the zAgile Platform to provide some interesting and useful functionality for the Software Engineering domain, although the functionality would be equally relevant anywhere else (our focus is only SE, for now :)).  We have integrated applications with it to both create content into the wiki as well as access content from it.   

       

We have enabled the wiki to become a valuable 'Knowledge Repository' rather than a 'Content Repository'  .

    

·         First, we have extended (or constrained, depending upon your point-of-view) the general free-form annotation capability of SMW with well-defined (and expressive) set of ontologies for the Software Engineering domain.  Thus, the wiki now has the 'semantic awareness' of typical SE concepts, such as Artifact, Project, Person, Role, Team, Process, Work Product, Task, etc.  This set will continue to extend with richer and broader set of ontologies as we move forward.  Rather than allowing the users to arbitrarily create annotations, we constrain the wiki's semantic 'openess' by importing (or referencing) very specific set of ontologies.  This is mostly to ensure semantic integrity of the knowledge domain, as well as interoperability between tools (the core value of the zAgile platform).  If you continue to create arbitrary 'semantics' in your content, it is unlikely that anyone else will understand the meaning.  So constraining the annotations has been a critical part of our efforts.

·         Second, we have developed tools that generate 'annotated' content into the wiki.  Using zAgile's Method Composer, for example, you can define (or derive from) a methodology that may be relevant for your organization or project -- and publish it on the wiki with appropriate annotations that describe Lifecycles, Milestones, Tasks, Documents, Roles, etc. Using our Doc2Wiki converter, you can take MS Office, OpenOffice or PDF files and load them into the wiki in a WYSIWYG form but with annotations that describe basic properties such as Creation/Modification Dates, Author, Subject, Title, etc. but also allow you to extend the semantics of the documents based on the type being uploaded (an Invoice, a Status Report, a Project Plan, etc.).   

    With these applications and widgets generating 'annotated' content on the wiki, you can now begin to organize this content using simple queries.  For example, a set of pre-defined templates (with embedded queries) can now automatically generate My ProjectX page on the wiki.  A page that includes sections containing My ProjectX Milestones, Processes, Phases, Teams, Roles, Status Reports, Invoices, Artifacts (and types), etc.   None of this needing to either be organized or maintained manually.  Based on the templates and queries, any combination or composition of pages is possible, thus allowing you to create virtual binders of projects, products, people, processes -- at will -- and share it across the organization.  This has been done before by many others using wikis, but only manually, and most of the time, such content has been incomplete and out-of-date.  Always a good start but not sustainable enough through the project lifecycle, therefore, generating lots of useless content.   

• And finally, we have extended the typical search capability across this content using our Semantic Search engine.  This is a slight paradigm shift to the way we normally use search.  Rather than searching on keywords which can return any type of content match, now you can search for a specific concept.  In this model, for example, one is either looking for a Person or Document or Project or Product-related information.  Thus the search-string provided will return results that match the concept being searched on.  Performing a search  on a document with the string "Lucas" returns documents authored by Lucas.  Similarly, a search on a project with the string "Lucas" will return Projects in which Lucas may have played some role.  Rather than returning free-form result set, the search not only returns the concept being searched but also relevant properties and relations to other concepts (Document X -- authored by Lucas; created on Jan 19, 2008; copyrighted by zAgile Inc.; associated with Project Y; created in Inception Phase, etc. …) .

 

And of course, this search engine exists outside of the wiki (as a portlet) -- another example of the ease of interaction of semantic data with external apps.

 

-Sanjiva

Prague, Jan ‘08

IM Everywhere!!

Well, at least wherever you can get a cell phone signal.  I recently tried a couple of IM apps for the Blackberry (Pearl) from  ShapeServices which support Skype (IM+ for Skype) and  all other protocols (IM+ All-in-One).  Since at zAgile we run our own chat server, I finally can stay connected with my teams in South America on either one of the two servers from wherever I am (which currently is Prague).  The Pearl comes with a few standard clients (Yahoo, MSN, etc.) but these apps from Shape Services are really starting to become valuable for us because they are allowing us to stay in touch across different timezones and at all times.   I can't overemphasize the value of such apps and gadgets for operating distributed environments.  Beyond emails and sms, this is totally realtime and much more impactful (as IM is anywhere else).  Add to this the iPod with Safari and WiFi support and I am almost productive anywhere I can catch a WiFi signal :)

-Sanjiva

I love tech gadgets :)

The zAgile Portal -- on an Apple Touch iPod -- for times when you happen to be in a cafe in Prague without a laptop but still need to stay in touch with your software engineering projects :)

 

Web 3.0 at VLAB

Well, that was the billing.  It was meant to be an event to discuss Web 3.0    "What lies on the horizon? Will Web 3.0 usher in the long awaited vision of the semantic web, as proposed by “Father of the Web” Tim Berners-Lee more than ten years ago? ", etc. etc, etc…

   

The event featured a panel of entrepreneurs with proven track records who are also currently engaged in various implementations of semantic web related technologies in their new ventures.

       

And to top it off, a moderator who is a 'Technology Forecaster/Futurist" -- someone well known, respected and published.    

   

All that set the stage for an exciting topic.  At zAgile, technologies associated with semantic web have played an important role in our growth and evolution.  They are also core to our vision and platform.  So obviously, an event like this with such high profile billing would be enticing.  A great opportunity to learn about how others are applying these technologies and their perspectives and experiences with it. 

 

Earlier in the week, I discussed this event with my team in Vitória, Brazil.  Outside of the various international conferences on semantic web-related technologies (many of which are still very academic and research focused), I told them that this would be the event that profiles how people are leveraging these technologies in their ventures.  They are well aware of some of the activities and contributions that have emerged out of Stanford (ex: Protégé from Stanford Center for Biomedical Informatics Research) so they were quite excited for this as well.

 

Alas, it didn't quite turn out as we had hoped or expected.  On the contrary, it was downright pathetic.  What started with some light-hearted humor quickly became an exhibition of some very smart people seemingly mumbling, fumbling, stumbling and bumbling their way through the key concepts.  Their version of this "Improv" was to decide on the spot whether or not to discuss RDF (could one of you at least spell it?) OWL or talk about  ontologies.  No one seemed prepared to articulate the basic concepts or why they are relevant to the discussion.  Even worse, their idea of the semantic web seemed stuck on making search work better than Google.  I am sure this isn't all they think of the semantic web (at least I hope it isn't).  There appeared to be total confusion about how to even define what constitutes an application as a Web 3.0!  Wow!  Before we get into the semantic web stuff, guys, let's first define the semantics of this forum.  Does it have a purpose, an agenda, a theme, an organization, an audience, etc. etc.?  It would have been a good start.  Turning an expected discussion on an emerging technology into an Improv comedy routine -- NOT a good idea.  Sorry.  I didn't pay for that. 

   

Whether the moderator had a hidden agenda, or there was a moral to the story to be revealed at the end or the whole show was just an improvised display to prove that semantic web is far from being realized as a practical vision -- I don't really know.  I guess I got fed up way too early and felt compelled to make my exit.  I had made an hour long trip to get to this event and with another hour looming ahead, I could not afford to waste any more time here.  This truly was such a pathetic display of conducting or moderating a discussion related to some very promising technology. 

   

I have been to VLAB events before (see my earlier blog titled Zimbra and AJAX at Vlab's Feb Event) and have appreciated the topics and the presentations.  But this unfortunately left a very bad taste.  This event is not supposed to be a crapshoot.  While VLAB just got SUN and Morganthaler as their latest sponsors, they lost one member of their audience. 

    

-Sanjiva

zAgile at WOMSDE 2007

zAgile's Lucas de Oliveira Arantes and Felipe Frechiani Oliveira presented two papers (SCM and Collaboration Ontologies) at this year's WOMSDE (Workshop on Ontologies and Metamodels for Software and Data Engineering) in  João Pessoa, Brazil .  WOMSDE was held in conjunction with SBES 2007 (Simpósio Brasileiro de Engenharia de Software aka  Brazilian Symposium of Software Engineering 2007) -- the biggest such event in South America.

Evolving a Software Configuration Management Ontology
Lucas de Oliveira Arantes (zAgile Inc/UFES),
Ricardo de Almeida Falbo (UFES), Giancarlo Guizzardi (UFES/ISTC-CNR)

Towards a Collaboration Ontology
Felipe F. Oliveira (zAgile Inc/UFES),
Julio C. P. Antunes (zAgile Inc/UFES),
Renata S. S. Guizzardi (UFES)

http://www.sbbd-sbes2007.ufpb.br/en_index.php?section=womsde-papers

 

Web Semantica UFES!!

Local TV coverage in Vitória .   They are talking about the semantic web, and of course an entrepreneur from US :) visiting the software research labs.  Shown are the zAgile team members, Giancarlo and of course myself.   

http://www.youtube.com/watch?v=ei_r-WSoqgo

"Minimum Ontological Commitments"

In discussions with Professors Ricardo Falbo and Giancarlo Guizzardi -- two of the thought leaders in the domain of Ontologies.  UFES (Universidade Federal do Espírito Santo) is one of Brazil's top technical universities.

 

Empresário indiano em Vitória (denovo) !!

RUBY ON RAILS BUT NO INDIANS!! ¿Porqué no quieren a ningún indio?

(I found this post on craigslist while I was looking for an apartment in Buenos Aires). 

PHP5 & Ruby on rails (web2.0)

Reply to: job-265251708@craigslist.org

Date: 2007-01-19, 6:19PM ART

I am looking to assemble a team of developers in Argentina (must be in South America, no INDIANS!) This team would work together for a minimum 6 months. Must be available (all of you) to chat via skype, MSN/AIM/YAHOO/GTALK, and must not be working fulltime anywhere else.

We are trying to assemble a team of 2 or 3 maybe 4 if there are enough qualified candidates. The team will work on php/mysql and RoR development projects building Software as a service style programs.

Please send me examples of your sites, you do not need to be extremely experienced, just be fast, efficient, and responsible. Recent college graduates are also welcome if you can demonstrate strong fundamentals.

• Location: BA
• Compensation: full time salary with bonus at end of quarter and 6 months
• Telecommuting is ok.
• This is a contract job.
• Principals only. Recruiters, please don't contact this job poster.
• Please, no phone calls about this job!
• Please do not contact job poster about other services, products or commercial interests.

PostingID: 265251708

PS -- It is only ironic since there is an Indian (THAT BEING ME!!) in South America incubating a silicon valley software company (perhaps one of the very few who have ventured in this direction).

PPS -- No, I didn't get lost trying to find India.  That is old history.  I came here on purpose.

--Sanjiva, Buenos Aires, Feb 27, '07

Sanjiva en Chile!! Porque?

An online posting from Universidad de Catolica, Esculela de Ingenieria bulletin board:

2006-12-07 11:35

"El lunes 11 de Dic. en la sala Javier Pinto (DCC), se presentarán dos charlas a cargo de Antonio Cansado y Sanjiva Nath. Antonio es ex-alumno del DCC y actualmente alumno de doctorado en INRIA-Sophia Antipolis, Francia. Sanjiva Nath, es un conocido emprendedor de Silicon Valley con más de 20 años de experiencia en proyectos de gran envergadura (Ej. IBM Trigo) y que viene a nuestro país con ánimo de crear tecnología para ambientes de Ingenieria de Sofware."

12.00 pm: "zAgile's Product Suite for Software Development" (in English)
Sanjiva Nath, fundador y presidente de zAgile Technologies

http://dcc.puc.cl/noticias/index.html?idnoticia=103

El sueño tech de Sanjiva

• zAgile Inc. is a software development tools company that provides a comprehensive set of open-source tools that integrate all stages of a software development cycle -- from concept to delivery, filling a key gap in a $4-$6B Application Development Tools market that is currently dominated by highly specialized and “lifecycle-stage” products.

• zAgile's product suite is directly addressing the inefficiencies in software development and maintenance cycles that have continued to result in increased delivery costs, product failures in the marketplace and poor customer satisfaction, especially when they involve distributed teams and offshore development initiatives.

o

http://www.zAgile.com

The First Law of Software Development aka "The Law Of Four Forces"

Software Development organizations tend to "lean on" or "crank up" processes in the delivery cycle in an attempt to achieve higher predictability.  For all the obvious reasons, achieving predictability becomes the key initiative for the product delivery teams as well as the key source of concern for the executive team, the board, customers and other stakeholders outside the delivery organization. 

By predictability, I refer to the questions of 'when' software will be delivered, 'what' it will contain and 'how' it will perform for the end users.

Does cranking up process alone provide this predictability?  I don't think so.  Besides process, there are other forces also at play in a software development lifecycle that influence the delivery predictability and the ultimate outcome. 

In fact, I believe that a software development lifecycle is controlled by four significant forces that simultaneously act on and influence the lifecycle in terms of time, content and quality (the "what", "when" and "how" of above) of software.  These four forces are:

• Knowledge --representing the knowledge that is needed, acquired and eventually embedded in software.  For more on this concept, refer to The Laws Of Software Process** by Philip Armour.
• Community -- representing the community that is engaged in the delivery cycle towards acquisition and capture of knowledge, their skills, roles and responsibilities

• Collaboration -- representing the collaboration needed to accomplish various tasks and activities towards software development and delivery

• Process -- representing the process that is used to manage and drive the development and delivery mechanics

Quite analogous to the Law of Parallelogram which allows us to measure the resulting impact in magnitude and direction of two forces acting on a body simultaneously, I am proposing the Law of Software Development, aka the Law of Four Forces (or Sanjiva's Law of Software Development :)).  These four forces simultaneously act on the development cycle and the Law of Software development provides a means to measure (or predict) and influence the outcome -- a product of time, content and quality.

The rationale for treating these as forces or vectors is that each has its own influence, also in magnitude and direction, towards the overall lifecycle.  An optimum delivery of software with respect to time, content and quality requires a deliberate and proportional balance between each force.  Conversely, an out-of-balance scenario, unless deliberate, can potentially affect the efficiency of the overall delivery effort and significantly impact any one or all of the outputs mentioned above.

Furthermore, similar to a parallelogram, a weakness in one force can potentially put a significant burden on the others in an attempt to achieve the desirable (or any) outcome.  Agile methodologies are a clear example of the increase in collaborative tactics to overcome the deficiencies in the Knowledge force.  Here, the rapidly evolving business requirements and lack of sufficient knowledge ahead of the development cycle warrants added focus (or weight) on the Collaboration and Process forces by creating various iterative delivery models, directly engaging end users, trading off formal documentation, and so on. 

Agile, then, is an example of a deliberate manipulation of other forces when Knowledge is known to be a weaker influence.  In many real-life situations, there isn't a clear assessment or acknowledgment of the weight or impact of any of the four forces on the software development cycle and therefore the impact on the others is more accidental and uncontrolled.  I have seen many situations where unplanned and unwarranted increase in collaboration results as a way to accommodate lack of Process and Knowledge forces.  Here, the predictability falls off because the organization has not clearly assessed the forces at play and their individual impacts.

So the lesson here is towards gaining a deeper understanding of the Law of Four Forces as it influences predictability of software development and delivery in your organization and managing each one to improve the overall predictability and the outcome.

-Sanjiva, Bangalore, August 19, '06

**In his book "The Laws of Software Process", Philip Armour asserts that software is not a product but a knowledge medium.  He formulates his Laws of Software Processes in the context of "the knowledge that is available for implementation into an executable system".

PS -- The interaction of individual particles and behavior of large-scale matter in the universe is also controlled by Four Forces (not necessarily those mentioned above) -- in this case, Gravity, Electromagnetism, Weak and Strong Nuclear force.  Coincidence?  I think not.  It is another one of my attempts at 'Unifying theories' ;)

Web 2.0--Qu'est-ce que c'est?

It’s a bird! it’s a plane! … no its Web 2.0.

In the past few weeks, I have attended a few presentations on Web 2.0 at various valley forums (TIE, Venture Labs, etc.).  In all of these, the definition of Web 2.0 seemed pretty arbitrary, often driven by a 'personal agenda' (i.e. whatever a panelist is peddling that evening), or professional alignment.  But what really is Web 2.0 never became clear or consistent, even when some of these folks were challenged to define it--and that included the analyst on the panel (i.e. not just the peddler). 

Are people confused by it or are they seeing it as an opportunity to define their own purpose?  Is Web 2.0 an abstraction for anyone to sell whatever as they see appropriate?  Is it a catch phrase or is there a specific problem being addressed through a set of related technologies? 

I walked away either seeing some cool technology (ref: Zimbra) or realizing the success of paradigms (Wikis in the corporate  or enterprise world, ref: SocialText).  But I also walked away frustrated because no one could provide a satisfactory definition (some even avoided it) of Web 2.0.  What must I expect the next time I attend a Web 2.0 forum?

So, I decided to offer a few possibilities on what it could be, based on all that I heard, saw and read.  You can take your pick because it seems that any of these definitions will apply.

• Web 2.0 is a cool agenda for a conference, since we have had virtually no leadership or advances in consumer technologies (except wireless/mobile phones arena) in quite some time (we have missed a wave altogether), we need exciting topics for yearly conferences.  We just can't keep waiting for something really 'cool' to emerge.

• It’s a way to get in the door of potential investors ('our product is Web 2.0 so we are cool and you should give us your money')

• It's a medal or ornament achieved via a certification process for your website (picture a cool 'Web 2.0 certified' logo or better yet, 'send us your website link and we will tell you if you are Web 2.0').

• It's a trend.  As trends go, we do not need to understand them but just believe and follow (we are Eric Hoffer's True Believers)

• It's Wikis.  They are invading the world.  They must be Web 2.0

• It's AJAX.  We haven't see such cool UI on the Web so it must be Web 2.0.  The last time we saw anything like it was in the client-server world but that was unfortunately a bust and we don't need to go there

• It's whatever Google does.  Their stock price alone defines Web 2.0.  If it goes to $500 this year (hmmm!), it could be defining Web 3.0

• It’s a combination of AJAX, web services and social collaboration--whatever that means

• It's enterprise apps based upon open source, LAMP and AJAX, again, whatever...

• It's a stop-gap measure of feature/functions until we really figure out  how to deliver user-friendly applications on the web, since we have consistently failed to do so for either the consumers or the enterprise (other than retail, search engines and porn). 

According to one billing, Web2.0 is the next-generation of internet applications and services, such as Blogs and Wikis.   Hmmm!  I don't think so.  There is nothing 'next gen' about either Blogs or Wikis.  The fact that we are only now realizing that people want a simpler way to publish and share content doesn't make it 'next gen'.  It simply means that the first gen was over-engineered because of our lack of understanding of what anyone wanted out of this technology.  Overcoming initial failures does not become 'next gen' (or 2.0).   I think we have regressed with these paradigms.  I think that they are a fad and quite short-lived.  (See future blogs for more details on why).

I also think that we should not care about Web 2.0.  There are definitely some exciting applications emerging that exploit the web and that offer us some very interesting opportunities or insights with respect to where we must shift our creative focus, but we don't need specific labels to validate their existence or value.  We simply need to recognize them on their own merit.

-Sanjiva, Orinda, March 29, 2006

Zimbra, AJAX and Web 2.0

Is AJAX a 'cool' technology or something far deeper that is capable of spawning or facilitating 'new disruptive models'?  Is it a key definer or component of WEB 2.0?  Does it offer sustainable value, particularly to the enterprise community?

These questions were raised and addressed this week at the VLAB (Stanford-MIT Venture Lab) monthly event.  The topic was engaging enough to compel me to offer my own perspectives on these questions with a focus towards the 'Enterprise'.

The most compelling pitch for the propositions above came from Scott Dietzen's demo of the Zimbra product.  I could hear oohs and aahs from all corners of the auditorium.  Zimbra has done something quite spectacular to the email application by providing a very collaborative and rich user-interface using AJAX.  This is definitely a 'next-gen' email client.

But.  (here it comes).

While people saw cool AJAX-driven UI 'stuff', I believe that it is the back-end integration (via Zimlets) that ultimately delivered the functionality that 'wowed' people.  So this wasn't totally about AJAX, although its potential for a rich UI is not being debated. 

On the same thought, discussions through the evening also made me wonder whether this (i.e. AJAX) is yet another 'fad' or something with sustaining value, particularly as it relates to the Enterprise.  The evening brought back memories of other technologies of the past (as Om says--'a bubble ago), that were also equally exciting and promising in their day but somehow failed to make 'satisfactory' inroads into the corporate community.  Portals, in particular, come to mind right away but there is a long list of others. 

I have come to believe that these failures of the past (and possibly near-term future) were as a result of our inability to provide:

1. A semantic substrate that is shared across applications, processes and business communities to leverage them effectively in various workflows and collaborations,
2. A pre-instantiated (out-of-the-box) offering of functionality from vendors rather than the 'toolkits' that they have continued to pitch
3. The lack of (or relatively immature) standards related to integration of applications, processes and data in the Enterprise.

So, I believe that until we resolve these challenges, we need to exercise cautious optimism in claiming technologies that are 'ready' to revolutionize the 'Enterprise'.

BTW: This event was clearly VLAB's most exciting, entertaining and engaging one that I have attended thus far.  Scott's presentation was highly charged, passionate and very exuberant.  I hope they really succeed with their vision and the business.  The panelists had great chemistry and obviously Om Malik (first time I have heard of him) brought a brash sense of humor to the forum--so overall a great evening for technophiles (at least for me).

 

http://www.vlab.org/Htdocs/001.cfm

http://www.zimbra.com

-Sanjiva, Orinda, 2/22/06

Software Predictions for 2006 (At a TIE monthly event)

At a recent TIE monthly meeting, the topic was "Top 10 Software Predictions for 2006" (an obvious one for this time of the year for any domain of interest).  The panel proposing these predictions consisted of Ann Winblad, Gary Morganthaler and Yogen Dalal -- some of the leading valley veterans.  The topic reminded me of the weekly NFL predictions hosted by sports-oriented programs.   Ann Winblad summed it well when she said that the VCs are opportunists (as opposed to trend-makers) and it was up to the entrepreneurs to establish the trends and feed the predictions.  It makes sense.  Why are we spending 2-3 hrs on a Tues nights listening to a few VCs making their predictions for how the next twelve months will pan out.  It isn't likely that anyone will walk out of the session and begin reconstructing their biz plans based upon these inputs.  More than likely, I guess people want to hear what is on the minds of these veterans these days and perhaps use that as a way to schmooze with them (and/or get inspired) :)

Anyway, it was quite intriguing to hear how these folks viewed the upcoming trends in the industry.  For example, they believed that enterprise software has evolved towards composite applications and belonged to large players.  They did not see any opportunities for innovations in this space.  Curiously, there wasn't much dialog on the productization of open source (ref: SpikeSource.com). 

Google was a focus of the discussion in terms of its tactics for producing rapid innovations.  There were speculations regarding what it (and Steve Jobs/Apple) will do next in their respective spaces.  A few even wondered whether the Google stock will get to $500 in 2006 (obviously not relevant to the theme but clearly on people's minds).   

Local WiFi networks, mobile devices, set-top boxes (as hubs in the living room) and peer-to-peer technologies (bitTorrent) also dominated much of the discussions. 

This was my first visit to a TIE event.  I was impressed both with the organized sessions as well as with the audience.  A 'must attend' in the future. 

Sanjiva, Orinda, Dec 3, 2005.

http://www.tiesv.org/Home/AboutTiE/index_html/view_document

http://www.spikesource.com/

http://www.bittorrent.com/introduction.html

De-mechanizing Software Development

Efficiency in software process and delivery is achieved in large part through our 'qualitative' understanding and construction of the plan.  This is in stark contrast with the common propensity to focus on the mechanics of delivery which makes everyone involved acutely aware of the project milestones, processes and tasks but takes the focus away from the strategy behind the plan, risk assessments, mitigating factors and the navigational choreography needed to achieve 'success'.

Over the past few decades, there have been at least three generations of 'process wars' as the software processes, methodologies and technologies evolved to meet the accelerating needs of the technology and society.  With each one of these paradigms evolved a generation of tools and infrastructure--all supporting optimizations in the development and delivery processes. 

There is no doubt that these evolving processes and tools contribute towards making a development team efficient in its delivery--but--BUT--it's not enough. 

At all levels, whether an engineering executive, a project or development manager or an engineer--everyone needs to have a strong (relevant to their individual roles) understanding of the tasks, plan and project at hand.  None of the tools, technologies or platforms that are available on the market today support or enforce this level of analysis or understanding.  This in turn allows all key participants in the software delivery to resort to regulating the mechanics of the delivery--in other words--becoming and acting like robots. 

Robots cannot deliver software;  humans are having enough trouble with it. 

Given that software development is a precarious balance of 'art' and 'science', primary focus on delivery mechanics and tools increases delivery predictability BUT also an overall failure of expectations in the end.  If we have not understood the overall strategy, plan or risks, I assert that we cannot succeed in delivery (i.e. satisfy our customers) by focusing only on the mechanics of execution, no matter how precise we are in meeting the delivery expectations and 'defined' goals. 

Sanjiva, Orinda, CA, Nov 18, 2005

Whither "The S-Curve" ;)

Musings on a Friday night with a 2002 Cuvaison Carneros Pinot (medium bodied, dry, fruity, smooth and refreshing)

Success with Offshore Software Initiatives - Establishing Key Objectives (Part 2)

PRELUDE: This is one of a number of briefs that focuses on my perspectives on offshore software initiatives and specifically the keys towards achieving success with them. 

The challenges inherent in software development, which have led to continuously evolving processes, methodologies and tools become multi-dimensional and more complex when the project is outsourced to a partner or a team in a different geography (see my earlier entry titled "Outsourcing The S-Curve", http://sanjiva.typepad.com/thescurve/2005/10/outsourcing_the.html).  In the offshore context, you face a number of other factors, such as culture, language and time zone difference, that heavily increase the complexity of the undertaking and influence the mechanics of execution of these projects. 

Why do so many offshore projects 'fail'?  Why do people sometimes refer to offshore as "the valley of despair"?  Why do we keep trying?  In this series, I provide some of the answers to these questions indirectly by addressing the keys that are critical to succeeding with these initiatives.

Setting A Common Objective (contd.)

Why is it so important to set an objective for your offshore initiative (or at least set some objectives and their relative priorities)?

As I indicated in an earlier Blog entry, the strategy for outsourcing or "off-shoring" and the execution mechanics are heavily influenced by the specific objectives that are set and the results that are desired by the organization.

Here are some of the areas where the objectives influence the strategy you develop and the ways in which you execute the relationship and the offshore engagement (some are more obvious than others):

Geography --Where do you go to look for a partner?   If it is Toronto, Canada then you are not likely to "Follow-the-Sun" (at least not for more than a couple of hours) if your local team is in California. Geography also influences costs.  Beijing may be cheaper than Bangalore which may be cheaper than Toronto, etc. (although the rates alone do not ensure cost savings).

Partner--The type of partner you choose is influenced by the type of expertise you want to  leverage (language translations, performance or platform QA, integrations with tier-1 ERP solutions, etc.) and/or to build, i.e. build a team that needs to become proficient with your application, domain and customers.  Similarly, if you desire to scale the team quickly then 'offshore' does not need to be a parameter in the equation.  If that is the objective then nothing specifically relevant is gained by separating the team by 12 time zones unless there is a significant advantage in recruiting desired talent in a particular geography.

Parnership model--Is it a one-time project or a task-level engagement (i.e. you develop the software and the partner performs the translation or QA or platform testing or …), or is it a team that you build that will be responsible for end-to-end product development that will dictate the type of partner that you will select for this venture.  Moreover, it will also dictate the engagement model, since a number of more established offshore service providers support a number of different engagement models depending upon your specific objectives.

Strategic Engagement--Is the assignment project-based or a desire to build a team that will be an integral part of the organization.  Will the team eventually become part of the organization?  Will it use its own tools and processes to delivery the results or integrate and incorporate yours (referred to as Build-Operate-Transfer model)?   Will you eventually acquire the team?

Cost Saving--Cost saving can likely happen in two scenarios -- 1) when you are leveraging expertise, technology, process or tools that exist; 2) when you make long-term investment and measure it in the long-term.  It doesn't happen if you spend 3x the time training a new team to deliver something that is likely to be a one-time deliverable.

Team Culture and makeover--Is the team only going to take over maintenance or engage in new product development or engage in R&D activities?  This influences the type of investment needed into the partner, the team, its engagement with the local team, its makeover (innovation versus delivery focus), processes and skill sets.

There is a lot more to this but at least this list helps one appreciate the need for a common set of 'objective(s)' for the offshore initiatives.

Sanjiva, Orinda, CA,  Nov 5, 2005

Success with Offshore Initiatives--Establishing Key Objective(s) (Part 1)

PRELUDE: This is one of a number of briefs that focuses on my perspectives on offshore software initiatives and specifically the keys towards achieving success with them. 

The challenges inherent in software development, which have led to continuously evolving processes, methodologies and tools become multi-dimensional and more complex when the project is outsourced to a partner or a team in a different geography (see my earlier entry titled "Outsourcing The S-Curve", http://sanjiva.typepad.com/thescurve/2005/10/outsourcing_the.html).  In the offshore context, you face a number of other factors, such as culture, language and time zone difference, that heavily increase the complexity of the undertaking and influence the mechanics of execution of these projects. 

Why do so many offshore projects 'fail'?  Why do people sometimes refer to offshore as "the valley of despair"?  Why do we keep trying?  In this series, I provide some of the answers to these questions indirectly by addressing the keys that are critical to succeeding with these initiatives.

Setting A Common Objective

Success with your offshore initiatives will begin with an agreed-upon set of objectives and priorities of these objectives by key stakeholders in the organizations. 

I am a strong believer that any initiative must begin with a single primary objective.   The primary objective that you set for your offshore initiatives has a significant influence on the strategy and mechanics of execution throughout the life of the initiative (I will elaborate in a future entry).  The emphasis here is on a 'single' (or primary) objective because I have often found that multiple objectives (or agendas) exist within an organization for 'offshore-ing' software development and more often these tend to have competing (if not conflicting) priorities, disrupting influences on strategy and execution and vastly differing expectations of results.  Of course, as stated earlier, multiple objectives can be managed through priority setting but there should still be a single goal for why this needs to be undertaken.

So, why do you want to develop software across geographies, time zones and cultures?   

I can think of several reasons (not in any relevant order) along with the common rationale, wisdom or belief associated with each:

• Cost savings (most intuitive) 

Development costs are considerably less overseas

• Scaling of the engineering team 

You can hire faster, build and expand teams more rapidly

• Rapid product delivery

To deliver more product and features in the same amount of time

• Outsourcing mundane or tedious projects

The need for the 'home team' to focus on 'cool' stuff

• Exploiting time zones ('follow-the-sun')

Developers/testers working in multiple timezones on the same projects will give us an extended cycle in a single 24-hr period

• Separating development paradigms

R&D in one zone, product development in another, different teams, different processes for each

• Leveraging specific expertise of a partner or vendor

• Outsourcing product maintenance

The grunt work can be handed off to someone else while the organization focuses on product development

• Improving product quality

Increasing QA cycles or bandwidth through specialized offshore teams

• Impressing the board members and investors

Well!!  They believe in it so why not, even though we may not be clear about what we want to accomplish

• Adding perceived value to the organization

They are not our salaried employees but they can be part of the overall headcount if one is to measure our assets

Not all of these are necessarily in the same class of objectives that people often set for this initiative but the key here is that stakeholders within an organization will have different expectations depending upon their perspective of the reason for the initiative.  It is most critical to align everyone to the same understanding of the goal(s) that need to be achieved through this venture.  They need to understand it, agree to it and support it.  This applies to the Exec team, the product development team, the sales team and everyone else.

In the next blog entry on this topic, I will focus on ways in which these objectives can alter your strategy and execution mechanics.

-Sanjiva, San Francisco, November 5, 2005

Outsourcing The S-Curve

In my experience, outsourcing software projects (whether onshore or offshore) has more often than not failed to meet delivery or cost expectations.  I have seen this phenomenon when working with major consulting firms as well as with smaller boutique firms, whether the project teams were located in the same building or a dozen time zones apart, and I have seen it for projects of all sizes and complexities.  I assert that a key contributor to this failure of expectations is due to the fact that almost all of these projects have had non-repeatable characteristics (new features, new paradigms, new teams, etc.) and we fail to account for (or sometimes do not want to accept) the factors related to the S-Curve when we pass on the responsibility of these project to a third-party. 

Of course, this failure to meet expectations is not to be equated with a failure to deliver the end result (a product or successful project), since competent teams and leaders find a way to make that happen.  But the costs and/or timelines often meet a significant mismatch in expectations. 

So why is The S-Curve so significant, especially when dealing with outsourcing?

I believe that through experience and daily interactions, we develop an implicit grasp of the functioning of the internal teams and adjust our expectations appropriately with regards to the processes, factors affecting delivery and eventual outcome of projects.  But none of this is possible with a third-party since there isn't the same amount of visibility (if any) into these factors.   This forces even a greater emphasis on identifying, quantifying and including the factors into the delivery plan.  This process is obviously easier if you are dealing with an experienced partner with an established team than with one that is about to bring a team together specifically for the sake of the project.

With respect to the type of factors to be taken into consideration for these projects,  refer to the article by David Anderson titled "The S-Curve Explained" (http://bdn.borland.com/article/0,1410,32411,00.html) in which he points out a number of factors that contribute to The S-Curve phenomenon both at the start (Team Formation, Knowledge Sharing, Tools, Environment, etc) and end (project integration, bugs, etc) of the project. 

While his focus is towards management of Agile Techniques on software projects, the concept can be generally applied.  You may even add or take away from this list based upon your own experiences and team maturity.  The point here is simply that these factors need to be applied to the plan and measured (however quantitatively feasible) throughout the project's timeline (and during post-mortems) to minimize the mismatch in delivery expectations.  Post-mortems would facilitate in identifying key improvements for the next phases of the project, if the relationship and work with the same partner are to continue.

Sanjiva, San Francisco, Oct 30, 2005

 

Software as a Knowledge Medium

Often in the context of managing software development and even the business around it, we tend to invest much more time and effort focusing on the process and mechanics of software delivery and much less on the content itself.  As a consequence, there is insufficient investment into the product definition (or elaboration) process and resulting unpredictability with regards to the success of the product in the marketplace (or its alignment with customers' needs).  While the organization focuses on the dates of delivery as the key milestones to achieve and celebrate, it fails to set specific expectations or measurement criteria with respect to what the product needs to achieve in the market or with customers.  I have rarely seen processes or operational structures in place that can 'directly' facilitate such measurements or accountability. 

Similarly, people are more apt to accept the failure of certain features in the marketplace ("customers and markets are changing too fast and product couldn't be delivered yesterday when we really needed it") than delays in shipment.  The exec responsible for feature/content of the product will often have a clear idea of what they could easily sell in the market today and even support the need to invest more heavily in engineering to achieve the "immediate" delivery needs.  But  they are less clear or committal towards even the near-term future.  In the absence of the sales team meeting its quarterly revenue goals, the typical response would be "if we had x features today, we could easily make the quota".  Of course, when those features are delivered, the target changes to the next delivery date on the roadmap (or so it seems, at least to me :))

As all this attention and pressure diverts to the engineering team, it is easy for them to feel that the organization is not taking the responsibility for developing enough of a vision or strategy (or a commitment towards this strategy) against which to focus its execution tactics.  The behavior of the sales and marketing teams is often viewed as 'deflection  tactics' to keep the pressure off of them.

Recently, I came across a presentation by Phillip Armour titled "Of Zeppelins and Jet Planes" in which he contends that software is a knowledge store and not a product, therefore, software development needs to be managed as a knowledge acquisition process and not a product production process.

While Phillip appears to focus on development processes and methodologies, I can easily relate the argument to changes in operational and organizational tactics and behavior to place a deeper emphasis on the decisions regarding 'what to build' rather than the obsessive focus on 'how' to build it'.   

This is not to suggest that there is always sufficient clarity with respect to the specific requirements that constitute a product definition or direction.  As Phillip points out, this is becoming more and more of a moving target, therefore, our methods must allow us to deal with such a moving target.  My point here is simply that this is something the organization must recognize and react to and not just the engineering team.

http://www.corvusintl.com/biograph.htm#Phillip%20Glen%20Armour

Sanjiva, Mallorca, Oct 21, 2005

The Art and/or Science of Communication

It is often difficult to appreciate the difficulty that we have in communicating with each other.  I presume that this is primarily because we take communications for granted and defer the responsibility for comprehension to the other party.  Conversely, we tend not to spend much effort in helping others understand the level of information that we seek from them to understand situations.   I feel this way because I have found lots of situations where people have struggled with ineffective communications and very rare instances where anyone has stepped up to focus on making it more effective.

People face communications challenges often and everywhere; they face them in relationships as well as in professional settings.  Communication becomes even more difficult when executive teams are assembled rapidly (in the process of re/building companies) and they need to manage their respective goals while attempting to influence the overall direction of the organization.

Within the context of a team, the difficulty in communications is compounded by a number of factors.  Some of these include:

• Personality and communications style (see note below on a Forte Institute profiling experiment)
• Cultural background
• Philosophy
• Experience
• Language and expression skills
• The chemistry (or lack of it) on the leadership team
• The trust level within the team
• The sense of security and overall support that each member on the team feels he or she has from the others
• The clarity of goals and objectives

These factors do not all weigh equally in influencing the degree of the gaps that exist within a team.  Moreover, I have come to realize that some of them (leadership, strength of the team and clarity of goals) can more than make up for others. 

Communications needs also differ from one individual to another.  While one CEO insisted on his team structuring their communications in the S-C-R (Situation, Complication, Resolution) mode ("we have x customers with y workload and are unable to support new efforts without z impact, therefore possible scenarios include …."), another one wanted the R-C format (ex: "just tell me that you need additional headcount to support the needs of new customers"; no additional details needed unless asked for).   

[In one company, the leadership team invested in the Forte Institute's Interpersonal Communications System (https://www.theforteinstitute.com/introduction/monograp.pdf)

and a consultant to help us appreciate the difficulty we were having in understanding and consequently working with each other.  Through this profiling scheme, it was determined that of the thirteen members on the team, yours truly stood alone in the top left quadrant (Dominant/Conformist -- implying someone who deliberates, is cautious and focuses more on the execution details and less on the big picture) while the other twelve were mostly Dominant/Extroverts -- more apt for the entrepreneurial types, not focused on consequences of their actions or execution details but more focused on the big picture and creative thinking).

Not to indulge into the details of Forte's science or mechanics, one of the things that became clear to everyone was that my deliberations over key technology decisions had often been mistaken for indecisions.  Similarly, being on the top left quadrant meant that I tended to focus a lot more on the execution details of specific decisions and recommendations and tended to relate our goals in the context of those details--clearly creating a mismatch in communications style with the others on the team.   

Beyond just appreciating our differences in personas and communications styles, I am convinced that there was sufficient depth and detail in such an investment to allow us to improve the overall effectiveness of our communication, should we choose to apply the needed effort.  We didn't and the results of this exercise proved futile and a wasted experiment.]

When faced with these circumstances, I have found that people will either resort to the comfort of familiar faces, choosing to work with peers and subordinates from prior organizations -- because the existing working relationship seemingly reduces the overall need for communications or start placing significant emphasis on details, facts and conclusions (and increase the overall quantity of outputs) rather than more qualitative assessment of situations. 

And this becomes even a bigger challenge when managing remote teams (regardless of their mandate, i.e. whether they are engaging in sales or development or any other activity).  Here the geographies, time differences, language and cultural factors became much more pronounced.  While we spent countless hours communicating status report, our understanding of the situation, status, risks and potential actions become increasingly limited.   Lack of effective communications here does not in itself lend to project failures but it reduces our ability to understand and manage the situation, thereby increasing the risk of potential failures.

In this context, I applied one simple technique with my team that worked quite effectively for the type of information that I sought from them, although it required trust and patience on both sides and mostly my needing to understand what quantity and quality of output I needed from them.  Rather than focusing on the output itself for various status reports, proposals, etc. that they would share with me, I spent more time on each line item asking them three questions:

1. Why are they telling me
2. Why should I care
3. What do they need from me (or someone else on the executive team)

As an exercise, we went through several presentations that they had for me and worked diligently through the line items.  The process was tedious and iterative but began to produce effective outputs.  It also forced me to focus on all the details and continue to provide them with relevant feedback so that they knew that I was focused on trying to understand the inputs.  And lastly, at the end of each session (or call), I would play back for them my understanding of the status or proposal.  To the extent that I could absorb it (in abstract terms), they got both encouraged and excited about their efforts.

What is the S-Curve

A few years ago, one of our board members had forwarded an article to me titled "The S-Curve of Software Development".  I have since lost the reference but I remember the overall message--that process introduction into a relatively young and immature development environment has some early costs with respect to the throughput of new functionality delivered over time, but the investment pays off as the scale and speed of new development increases as these processes are applied. 

This article was brief and its message fairly clear.  At an abstract level, it is also something that people have been trying to communicate for decades through various channels.  In this context, given a small startup with a young engineering team, it served to reinforce certain development paradigms and associated consequences on delivery plans and timelines.

For early stage software companies, the problem is multi dimensional and seemingly much more complex mostly because there is less clarity with respect to its overall mission and a greater need to be reactive, nimble and adaptive.  The problem involves more than negotiating or balancing the effects of process improvements on feature introduction.  When we are still attempting to define our market, products and customers, the clarity and definition of features, their priorities and complexities are all in constant flux.  It is analogous to the 'mathematical' challenge of trying to solve one equation with many unknowns.    

So while everyone finds themselves at some point on the S-Curve, there isn't a simple equation or recipe that plots the optimal path through it.  In my view, it has mostly involved applying intuition and experience and factoring in the maturity and leadership capability of the executive team and their ability to commit to a specific direction for the organization. 

I had dutifully passed this article on to some of my peers, needing to drum up support for our challenges in the development cycles.   As always, such communication generates occasional sympathy towards our plight but fails to set any concrete expectations or affects any specific behavioral changes, decision trees or execution paths in the executive ranks.  In retrospect, I realized that communicating abstract messages was not a productive exercise.  Not only were my messages, such as this one, lost on the team, but none of us always understood each other's challenges well enough (perhaps because each one of us was often communicating in similar ways).  Such reflections have since made me more aware of the need to deliver more concrete messages that are specific to the actions, decisions or behaviors that I am expecting to influence within the team and the organization. 

Through this blog, I hope to share some of the challenges, successful techniques and more importantly--failure scenarios that I experienced (and managed) while navigating through the S-curve.

Where are you on The S-Curve?

-Sanjiva,  Oct 15, Pt. Alcudia, Mallorca