The S Curve

Wikidsmart for OpenStack is Live!

2013-04-11T00:06:50-07:00

We are proud to announce that zAgile has recently engaged with the OpenStack Foundation to create the Activity Board, powered by Wikidsmart.

OpenStack is a leading open source software platform for building public and private clouds. The OpenStack Foundation drives its evolution and is backed by enterprise leaders include IBM, Cisco, HP, Red Hat, RackSpace, AT&T, VMware, Dell, Canonical, and others.

The development Activity Board for OpenStack provides a visual overview of all the OpenStack public activity of community members across multiple dimensions: contributors and organizations, projects and code-related contributions. From a single interface, you can easily surf OpenStack project content, whether it is coming from the Launchpad bug tracker, Git version control system or Gerrit code review application--all mapped against the OpenStack Foundation members database.

The intention of the Activity Board is to give the community a way to answer very precise questions like: who’s contributing to that particular project? What is that developer working on? Which commits/changes are related to a particular bug? Who’s joined the development community recently? etc.

And for OpenStack corporate members, an additional benefit you may wish to consider is to integrate your own internal tools with the OpenStack community project content to create your own composite internal dashboard, to provide your teams with instant and precise access to community activity and efforts. Wikidsmart Context Server’s approach enables you to integrate your tools to automatically build a cohesive view of all content. That means you don’t have to do extensive integration work which can be quite costly to build and maintain.

If you would like to learn more, we are featuring the OpenStack Activity Board in the upcoming events:

OpenStack Summit , April 15, Portland, OR: one long session to show the state of the art and to gather feedback

Webinar, May 2, 9am Pacific Time: Introducing OpenStack Activity Board, A Unified View of OpenStack Project Content

-Sanjiva

A 'Wikidsmart' Project Explorer in Confluence

2012-04-08T23:31:27-07:00

Since zAgile's Wikidsmart integrates concepts across tools and phases in the software lifecycle, there are a number of ways this integrated information can be leveraged by engineering teams. Recently, we have had a number of requests to present this information on a confluence page in a tree-like form, analogous to file explorers. For example, this would allow a tree view of all concepts (version, component, feature, design document, task, test suite, checkin, build, etc.) related to a JIRA project, regardless of where that information exists (Confluence, JIRA, Subversion, Jenkins, Salesforce,...). The explorer presents the consolidated view of the relationships, much like typical file explorers, such as the Windows Explorer.

We have now developed a widget that can provide this functionality within Confluence. Its most typical use would be to render all related information about a JIRA Projects. However, the usage is not limited to any particular 'root' concept. For example, if you have integrated Salesforce into the Wikidsmart platform, you can see a tree-view of all your CRM Accounts.

This simple to configure and customize widget macro provides a hierarchical (multi-level) view of JIRA projects and related artifacts, tasks, etc. in the example below. It supports the following features:

Customizable -- The root or base concept can be any concept represented in the Wikidsmart knowledge model. The examples here show root concept as JIRA project. However, it is possible to have the root as CRM Account, Document or Build, depending upon the context which the page represents.
Hierarchical -- execution of the macro will result in the tree-style listing of the root or base concepts. It will also render the nested relationships in a hierarchy, as specified in the JSON graph. The logical hierarchy of the example is shown below:

It can render multiple levels of hierarchical relationships without any constraints, with each level capable of representing heterogeneous concepts
It is dynamic and renders all relationships in realtime, as they are established.

Here is an example of an implementation of this macro. It shows a JIRA Project, Features, Components and Test Suites associated with each Project, Stories associated with each Feature, and so on (as shown in the graph above).

To explore this and other features of Wikidsmart, visit the Wikidsmart Sandbox.

You can also download Wikidsmart from Sourceforge.

Confluence 4.1 and Wikidsmart

2012-03-22T02:04:13-07:00

We have made a lot of progress towards adapting the Wikidsmart smart-forms templates for Confluence to be 'natively compatible' with Confluence 4, leveraging its rich user inteface for creating structured content that can be integrated with other applications and tools, including JIRA, Salesforce, etc.

Since there has been a lot of interest in Wikidsmart for Confluence 4, we thought to provide a sneak peak into what to expect. The new UI is rich, exciting and inviting. We are looking forward to the final form within the next few weeks.

We will continue to provide progress on this towards our goal of releasing the product for Confluence 4 by mid summer.

The form layout

The template-based form for structured content entry

The structured page in view mode

-Sanjiva

www.zAgile.com

Atlassian Chats It Up

2012-03-07T12:11:20-08:00

Kudos to Atlassian for expanding the collaborative and social aspects of the Atlassian suite even further with HipChat. And congrats to the HipChat team for joining Atlassian! Chat is of course a critical aspect to collaboration along with wikis, activity streams, etc. zAgile recognized this as such a few years ago when we integrated the Jabber-based Openfire server into the zAgile Wikidsmart platform.

As always, you can count on zAgile as the Atlassian software vendor partner to contextually integrate Atlassian products. zAgile's Wikidsmart open source platform and applications deliver tight interoperability, traceability, and federated search of content (Requirements, Issues/Tasks, Tests, etc.) across the Atlassian environment, as well as with other tools (Jenkins, Selenium, etc.) and applications (Salesforce.com, etc.).

And now HipChat's chat history content will be counted among those of course. In this way, HipChat conversations may be automatically tied (via key word/topic association) to issues in JIRA, requirements in Confluence, projects in JIRA, customers in Salesforce.com, etc. No longer will chats remain isolated but can be shared (to the extent desired) and associated with all aspects of the project.

This means historical chats may be part of the contextual content served to users whenever they are doing something (like creating an issue in JIRA) or performing a search for something. For example, if they are performing a search for a specific Requirement, now they can also see the associated historical conversations along with the associated Tasks/Issues, associated Customers, etc.

The Wikidsmart platform is about teams gaining efficiency and managers gaining insight into the software engineering activities by contextually integrating content and information. Now Atlassian's HipChat's chat history will be amongst that important content to drive collaboration in an ever more contextual way.

@AndrewLampitt
zAgile

zAgile Launches Open Source ALM 2.0 Interoperability Hub

2012-02-27T18:01:46-08:00

I am pleased to announce that all the power of zAgile's Wikidsmart's infrastructure and applications are now open source. Now all software engineering delivery teams and executives can easily and affordably overcome the problem of disparate teams and tools easily.

Whenever you integrate content, whether it's point-to-point or else with a service bus or traditional data federation layer, you get the same problem. The content is really only mapping data to data with no intrinsic understanding of the process or context of how the data is related. It's essentially dumb mapping. And it's a tedious, expensive effort that is difficult to measure in terms of ROI. So people simply don't do it. And that's why we still have the mess and an additional reason for software delivery deadlines being missed.

The Wikidsmart platform and applications offer the solution. Wikidsmart's core is a context server based on semantic web technologies. I determined that the integrated ALM solution had to have a number of characteristics. First, it had to follow open standards to be approachable to a wider audience. It had to recognize process, metadata, and context all in one. As I did my research, I realized that the WC3 standards body, led by Sir Tim Berners-Lee, was trying to solve a similar problem for the web. They led the definitions for semantic web technologies in order to interconnect content of the world's websites. I realized that some of those same technologies are the ideal vehicle for integration of content across the enterprise. Finally, we determined that our solution should be open source. Semantic web technologies are not yet widely known, and the open source nature tends to encourage people to experiment, learn, and contribute to extending the solution - and eventually adopt those solutions in a much more widespread way than closed systems would have otherwise. I think Big Data technologies like Hadoop and the NoSQL movement have demonstrated that well. So what we have ended up with at the core of the Wikidsmart platform is the Wikidsmart Context Server, which is an ontology-driven semantic framework that integrates content bi-directionally as a sort of semantic bus. It serves contextually relevant content from across the enterprise with the application or tool being used by the team member, or contextually composite information for example for an executive dashboard.

Of course, we are speaking of a paradigm shift in the way we think of content, metadata, processes. We went from mainframe to client/server to the internet. Those were all major changes that were inspired by big pains. I think we all agree that the pain is there in content integration. People are still trying to solve the problem with old approaches. People are still thinking SQL and point-to-point application integration primarily. We believe that open sourcing Wikidsmart will hasten its adoption and make the problem of lack of ALM integration a story of the past. I invite you to download <http://www.zagile.com/3/download.html> today for yourself and check it out.

At the SAP Cloud Community Inside Track Event on Feb 16 in Palo Alto

2012-01-30T11:19:32-08:00

I am excited to be speaking at this event on Feb 16. Its an opportunity to share and explore what cloud technologies provide in support of running and management of large-scale, globally distributed software projects.

Here is the abstract of my talk:

Cloud-based technologies can address a number of challenges involved in running and managing large-scale software projects using globally distributed teams. They can facilitate consistency of tools used by distributed teams throughout the software development lifecycle, from product definition to delivery. They can enable integration of heterogeneous tools, processes, participants and stakeholders across lifecycle phases, including customers and support. They can provide full transparency of all activities. And finally, they can leverage the elasticity of the cloud to support activity-bursts, such as those used with test automation and continuous build cycles. This session focuses on zAgile's cloud-based collaboration platform for software devleopment, that brings distributed teams together, providing a cohesive and unified environment with full visibility and traceability to facilitate rapid application development cycles.

Test Automation with Selenium, Confluence and JIRA using Wikidsmart Applications

2011-12-21T23:31:55-08:00

A demonstration of how the integration of Selenium with Confluence and JIRA using Wikidsmart Applications (formerly zAgile Teamwork) can give you added boost to your QA cycles. The integration of these tools enables full scale test management, automation, reporting and traceability for your release cycles.

Bringing Customer Relationship Management into the organization, with integration of Salesforce, Confluence and JIRA

2011-12-21T23:28:20-08:00

This video demonstrates zAgile's integration of Salesforce with Confluence and JIRA which brings customer relationship management to the rest of your organization. The integration of these tools enables the entire organization to be on the same page with regards to achieving highest levels of customer service and satisfaction.

Wikidsmart!! Knowledge Management

2011-11-04T01:34:01-07:00

Wikis have become entrenched in the enterprise as the most common ‘groupware’ application for collaboration amongst individuals and teams. They are easy to acquire, easy to setup, and easy to use for capturing ad hoc content that teams desire to share amongst themselves. It is not unusual to find dozens and sometimes even hundreds of wiki instances within enterprises. Whether it is Human Resources, Sales, Marketing, or IT, teams find ways of leveraging the convenience of wikis to publish and share information with each other.

While wikis permeate the enterprise, the convenience of capturing information, the ad hoc nature of this information and its lack of structure also contribute to the general failure of the wiki as an effective information collaboration tool. As the published content grows into hundreds and thousands of pages, it becomes increasingly difficult to organize, maintain, access, and search. It quickly loses credibility and becomes stale. Since there is no consistency or discipline with which information must be published or organized, different groups within an organization may experience varying degrees of success with their wiki.

Traditional wikis also present additional limitations that often constrain their usage as an enterprise groupware application. These constraints are not a critique of the inherent design of the wiki since it was intended as a simple tool for allowing people to capture information. We discuss them mostly in the context of the evolution of the wiki in the enterprise.

For example, the page-paradigm for representing content or information does not support ‘formal type’ declaration of specific content in a page or capturing any classification or taxonomic relationship between pages of information. Rather, it restricts the organization to simple page-level hierarchies. In multi-dimensional taxonomies, it should even be possible for a page to be represented in more than one classification scheme. And what about inheritance where information in a page may draw from that already represented in the parent page? or somewhere else external to the wiki?

Many commercial wikis support information integration from external sources through mashups. However, the context of such integration is implied based on its location rather than through any formal interpretable relationship with the page where it renders. There is no inherent capability of dynamically integrating content from external applications based upon page-level context.

Wikis do not support any federation of content. When there are hundreds of wikis in an enterprise, there is no mechanism for sharing information across them. Wikis in such scenarios represent team-level and department-level information silos.

In spite of these shortcomings, wikis have the potential to become an Information or Knowledge Portal within an enterprise and its users demand it. The emergence of semantic technologies, particularly as applied to wikis (aka Semantic Wikis) has gone a long way to address these gaps. To further read about the current limitations of wikis and how zAgile’s Wikidsmart semantic technology provides ways of overcoming them, specifically in the context of Atlassian’s Confluence enterprise wiki -- read the whitepaper on Enterprise Knowledge Management with Wikidsmart for Confluence available on Slideshare

Embedding Professional-quality Reports in Confluence with Teamwork

2011-09-14T15:58:46-07:00

As an enterprise wiki, Confluence is not only a collaboration platform for sharing user-generated content across teams and departments, it is also an "Information Portal". This capability is particularly enhanced by zAgile Teamwork which allows Confluence users to embed "pixel-perfect" reports in Confluence pages to create dashboards of information collected from various tools integrated into the zAgile platform.

This ability to design and embed visually rich, professional-grade reports into Confluence pages provides the business users with a much more Collaborative, User-friendly and Reliable environment for accessing critical business information.

Collaborative - because the reports, like any other wiki page, can be easily shared with other team members. They can be commented on, submitted for reviews (using JIRA Workflow) and incorporated in other contexts (ex: Bug and Build Activity Reports in a Project Release Dashboard). They can also be shared with others in conventional formats via exports (PDF, CSV, etc.).

User-Friendly -- because providing reports and dashboards within the relevant context of other related business information and data in Confluence pages eliminates the need for the users to access BI tools to generate adhoc reports - every time they need this data and manually collate them with other information context.

Reliable -- because the reports and dashboards offer real-time or near-time views of information captured across applications. All team members that need to access these dashboards can view the same information at the same time - and be assured that the information will not be outdated moments after it was produced.

Teamwork is able to achieve this through the integration of tools from JasperSoft -- the leading provider of Open Source Business Intelligence Software.

zAgile provides custom datasource for the JasperSoft iReport report designer -- to enable support for SPARQL (query language for RDF/XML).
JasperReport libraries are bundled with zAgile's zCALM Server to publish reports to various clients (including Confluence and zAgile Teamwork Portal)
zAgile's Plugin for Confluence provides macros to render JasperReports into wiki pages with realtime data

So the net result is:

The following macro notations in a Confluence page:

h4. Request Amounts by Functional Areas

{zreport:designFile=FRbyArea.jrxml|Title=Request Amounts by Functional Areas|exportFormat=html|embedded=true}

h4. Request Amounts by Functional Areas & Status

{zreport:designFile=FRbyFA Bar.jrxml|Title=Request Amounts by Functional Areas & Status|exportFormat=html|embedded=true}

Will give you this output on the page:

Executing JIRA Workflow Tasks from within Confluence using Teamwork 3

2011-09-13T14:08:41-07:00

Teamwork 3 provides much tighter integration of Confluence with JIRA Workflows using the JIRA XMLRPC API using the zAgile Teamwork plugin for JIRA. So it is now possible to initiate and interact with JIRA Workflow-based tasks from within Confluence pages and tables.

However, beyond this user-friendly interaction, the tasks and their states are also automatically linked with the specific entity (Requirement, Test Case, Document, Business Request, Invoice, etc.) in Confluence from where they are initiated (see example below).

The two-way linking can now provide the users with a friendly interaction with JIRA while achieving full traceability and reporting. Users don't need to access JIRA unless they need to edit/update task details. Since the integration is done using zAgile's zCALM Server, the information may be accessed anywhere in Confluence or JIRA. For example, you can query the Review Status of a Specific Document or Requirement, or the Test Execution Status of a Test Case using simple queries in the context of the Document, Requirement or Test Case, without having to go to its corresponding JIRA Task.

And of course, all of this is highly configurable, since it is accomplished using templates and macros provided with Teamwork. Visit the Teamwork sandbox to check out this and other features of Teamwork 3.

Here is how it works:

The screenshot below shows a couple of sample Requirements for Feature (Smart Search) in Confluence. Each Requirement may have associated Component(s), Stakeholder(s) as well as Review and Development Tasks. Review Task here is tied to an Approval Workflow in JIRA. The same can be done for Implementation Tasks.

Product Managers or Business Analysts defining these Requirements above can "Initiate" Review Sessions, and register the resulting outcome (Approved/Deferred, etc.) with the Requirement. Clicking on the "Initiate Review" Button against the Requirement 2 above will result in the automatic creation of a JIRA Task for Requirement Approval and return the Task link along with its possible next states as shown below.

From here, it is possible to take next actions against the Task, without interacting directly with JIRA.

zAgile Teamwork 3 - Advancing integration and interoperability of JIRA and Confluence

2011-09-06T02:04:42-07:00

Earlier this week, zAgile released Teamwork 3 -- a much anticipated and exciting release with significant focus towards improving the integration and interoperability of JIRA and Confluence for team collaboration and software project management.

With zAgile Teamwork, teams can capture Features, Use Cases, Requirements, Test Suites, Test Cases and other project artifacts in Confluence and use JIRA for managing the execution and workflow of related tasks through Projects and Versions -- with Teamwork automatically integrating the definitions with executions.

For example, Requirements may be captured in Confluence. And within Confluence, engineering managers can initiate Approval and Implementation Workflow Tasks, respectively, in JIRA.

Similarly, Test Cases may be captured and related to Requirements in Confluence but executed across Versions using JIRA -- with full tracking and traceability.

We believe that by separating definition from execution, organizations are able to get the best of both worlds -- using Confluence for capturing and sharing project artifacts, and JIRA for managing task execution, workflows and notifications.

The key features of Teamwork 3 include:

Easy creation of templated and parameter-driven Confluence pages
A redesigned JIRA plugin for easy installation and support for issue submission from Confluence
The ability to interact with JIRA workflow tasks from within Confluence tables
Improved Project Dashboards in Confluence
Pull-down Action Lists in Confluence for embedding Confluence page and JIRA Issue Creation Actions in simple tables
Integration of JIRA Users and Groups into zCALM repository
Integration of CRM concepts (Customer Account, Customer Case, etc) with the Software Engineering Lifecycle

and ... a lot more.

If you are a JIRA and Confluence user, Teamwork 3 is worth checking out :)

zAgile Teamwork 3 is now available for Confluence 3.5 and JIRA 4.3 (support for JIRA 4.4 coming soon).

-Sanjiva

I will be speaking at SemTech 2010 - June 21-25 in San Francisco

2010-05-26T20:43:17-07:00

A Jena-based Framework for Semantic Enterprise Information Integration (SEII)

EII (Enterprise Information Integration) and MDM (Master Data Management) have been the leading strategies in large enterprises for data integration across business functions. Initiatives driven by these strategies have been deployed successfully and proven effective in providing data consistency to business units as well as reducing costs of data maintenance. They also provide powerful analytics and business intelligence capabilities.

Semantic web technologies can offer a powerful complement to EII. Through the implementation of application-specific, collaboration and process ontologies, integration transcends from application data to the semantics of that data. Repositories may be central or federated across the enterprise - but they still provide a unified view of information. This level of semantic information integration may be tool or application-agnostic, domain-specific and easy to implement via a supporting framework.

This presentation discusses a Jena-based architecture for semantic enterprise information integration. This architecture has been implemented to integrate collaboration and tools within software engineering. It is also equally applicable in other areas. The resulting semantic information network can provide unique dashboards to decision makers.

In this session, we will address the following:

EII versus Semantic EII (SEII)

Role of ontologies and metamodels in SEII

A framework for SEII based upon Jena

Proposed connector architecture for integrating applications and tools

Demo

I will be speaking at SemTech 2010 - June 21-25 in San Francisco

2010-05-26T20:28:52-07:00

Orthopaedia - A Semantic Platform for Collaborative Knowledgebase Development in Orthopaedics

Semantic technologies have been aggressively applied in biomedical and healthcare domains to address a number of problems related to the representation, interpretation, integration and access of knowledge. These technologies include the development of machine readable thesauri and vocabularies, taxonomies, formal ontologies as well as NLP tools and techniques. And of course, there are emerging applications that are being developed to deal with these underlying metamodels.

This case study discusses a semantic platform that incorporates these technologies and metamodels towards the collaborative development of a knowledgebase in Orthopaedics. The platform enables users to easily enhance local content with publications from various sources, blogs, discussions, annotations, and automatically tag them with domain-specific terms, as well as make this information accessible across the enterprise to other tools and applications via a semantic repository.

We will also describe the current challenges in achieving coherency and integration across medical subdomains, and describe some the design decisions taken to overcome some of these challenges.

We will address the following points:

Overview of semantic technologies in healthcare
Challenges in semantic information integration across resources and applications
Objectives of the project
Discussion of technologies implemented
Review of strengths and weaknesses of the current state of technologies in addressing knowledge management issues in healthcare
Demo

Achieving Requirements Traceability with Confluence & JIRA, the rational (!Rational) way

2010-03-24T01:30:22-07:00

Requirements Traceability refers to the ability to link requirements to projects, change requests, development tasks, test cases and results, checkins, builds, releases and stakeholders. In other words - linking requirements with all relevant concepts associated with a software engineering life cycle. Given that Requirements drive the activities across the software engineering projects, maintaining such interrelationships can provide answers to some very critical and business-relevant questions relative to each requirement, whether they are related to business justification, auditing/compliance, delivery management or quality assessment.

These can be grouped by stages and constituents (some examples below).

Business Justification:

Who are the Stakeholders of each requirement?

Which requirements are being delivered in a release and for which stakeholders?

What is the business justification and cost of delivering a feature or requirement?

What is the ROI (once the costs are determined)?

Project Management:

Which release will the requirement be delivered in?

What are the risks and dependencies related to the implementation of a requirement?

What is the current state of a requirement with respect to development and QA?

Who signed off on it, who accepted it?

Which checkins correspond to code complete for a requirement or feature?

Which build includes a particular requirement implementation?

Development & QA

What are the design goals and motivations of a requirement?

What are the associated test cases and quality goals?

What are the associated use cases or user stories?

In typical engineering environments, some of these questions are difficult or impossible to determine, while others require a significant amount of tedious manual effort. The reasons can be mostly attributed to the heterogeneity of ALM tools and the lack of integration between them. Whatever the cause of this fragmentation of information, requirements traceability isn't always optional for organizations. Many expend significant human effort and co$t towards collecting sufficient traceability data to maintain their audit and compliance mandates.

Traditional ALM vendors provide their own integrated solution set to help their customers achieve requirements traceability. While they are able to address most, if not all, questions above, you have to invest into their entire portfolio of products and at significant co$ts. I have rarely seen an engineering environment that has successfully adopted a single vendor solution across teams and departments. For most part, such solutions end up as shelf-ware, reflecting wasteful and irRational decisions.

It is with this in mind that zAgile delivers its tool-agnostic and open source zCALM platform that is capable of integrating concepts across software engineering life cycle with the tools that you are using in YOUR environment.

And to take that even further, you can achieve significant amount of requirements management and traceability by simply integrating your Confluence wiki and JIRA issue tracking application via zTeamwork.

zTeamwork allows you to:

Capture features, requirements, use cases, test cases, test suites, etc. in Confluence in a semi-structured way using zAgile's smart templates.
Link them to each other using pre-defined relationships.
Create JIRA tasks, link them to various Confluence artifacts created above, so that you can now associated requirements with use cases, test cases, tasks, and bugs
View any and all of these links and relationships (including attributes such as status, completion, etc.) in Confluence or JIRA using simple queries. There are JIRA properties tabs that may be configured to provide 'dashboard' type contextual views of this information.
Search for these specific concepts from within Confluence or JIRA, regardless of where they are created. The search not only returns the matching result set but also all of the contextual relationships.

Teamwork's integration can be further extended with connectors for salesforce (link customers and cases to requirements and issues within your environment), Subversion (associate checkins with requirements) and CruiseControl (link requirements to builds).

With these connectors in place, you can answers ALL of the questions above with respect to requirements traceability -- without having to buy into expensive, complex and painful single-vendor solutions.

And since zAgile's solutions are tool agnostic, you can also plug other tools on its platform to achieve the same integration capability - via custom connectors.

Somehow that seems more rational than Rational :)

-Sanjiva

Test drive these features in the sandbox

Machine-based semantic annotation of content in Confluence Enterprise Wiki

2010-02-19T08:03:28-08:00

Annotation of content in any CMS, including traditional wikis, to provide contextual reference to any word or phrase is a common practice. I am doing that in my blogs as I write. When I reference specific topics or items, I go through the steps of creating links to them.

Wiki annotation, therefore, also typically involves highlighting words or phrases and associating each to some reference - an external link or another page within the wiki. It is a tedious process that involves marking up each word or phrase using specific wiki tags. It not only requires considerable effort but also a meticulous nature and some dedication towards creating meaningful content.

What if it were automatic? All you had to do is to add a macro at the beginning of your paragraph or page and everything meaningful within that text would automatically be annotated.

What if it were dynamic, so that the wiki content is still in its original form but all annotations are done when the page is rendered. The annotation would automatically reflect any changes to the reference. It would be more reliable and not prone to going stale.

What if the annotation was more contextual to your specific domain, to your business processes and functions, rather than highlighting of people, countries, organizations -- which may have less relevance when the text if referring to some technical requirements for a software component.

And finally, what if the annotation not only provided a link to some reference, but also some information about its type (is it a reference to a Project, a Requirement, a Task, a Bug, a Customer, a Software Component, ...)

Well, that's the capability that we will soon release for Atlassian's Confluence Enterprise Wiki in zAgile Teamwork and Wikidsmart products.

A simple, yet powerful capability in our upcoming release of Wikidsmart (Release 2.0) is the machine-based semantic annotation of wiki content. It is easier to play with this feature than to describe it to really understand the possibilities that it opens up in making content more meaningful and accessible in enterprise wikis. But here is an explanation:

By machine-based, I mean all you need to do to enable this capability is to surround the wiki paragraph with a macro (zannotate).

By semantic annotation, I mean that words or phrases in that paragraph that match any reference in our ontology-based semantic repository will be highlighted and linkable to additional information about the references. Since zAgile Teamwork ships with ontologies for software engineering, you will see annotations of words and phrases that reference instances of Requirements, Projects (JIRA Projects), JIRA Issues, Tasks, Bugs, Software Components, Test Cases, etc.

You can test drive this capability in the zTeamwork sandbox.

Here is what it would look like:

WRITE A PARAGRAPH IN A WIKI AND BRACKET IT WITH ANNOTATION MACRO

SAVE THE PAGE AND THE PARAGRAPH WILL BE AUTOMATICALLY ANNOTATED. CLICKING ON ANY TAGGED PHRASE WILL POPUP ITS REFERENCE CONTEXT

FOR EXAMPLE, REFERENCES TO JIRA ISSUES NOW ARE AUTOMATICALLY ANNOTATED WITH TYPE, DESCRIPTIONS AND LINKS TO THE INDIVIDUAL ISSUES

AND FINALLY, THE SAME APPLIED TO MEDICAL TEXT - APPLIED AGAINST AN ONTOLOGY DERIVED FROM MeSH (Medical Subject Headings) THESAURUS, ALSO IN CONFLUENCE - SHOWING HIGHLIGHTED TERM AND ITS SYNONYMS

- Sanjiva

To test drive this feature, visit our sandbox

Creating JIRA Tasks from within Confluence Requirements Pages

2010-02-18T16:40:06-08:00

One of the recent features delivered in zAgile Teamwork is the ability to create a JIRA Task from within a Confluence page and have the Task automatically inherit the context of the Requirement that is driving it. The use case description below explains this 'context inheritance'.

This is also a great examples of the interoperability that can be achieved between heterogeneous applications (JIRA, Confluence in example but almost any app) using semantic technologies. In this case, it is our zCALM semantic application server, that is enabling this seemingly simple scenario.

The use case is as follows:

1. Using one of the example semantic templates in Teamwork, you define a list of Requirements in a Confluence page

2. Each Requirement on that page may be linked to one or many Design Goals that is the motivation for it, as well as a specific JIRA Project in which it is planned for delivery.

Note: It is also possible to modify the template to associate all of the requirements on the page to a single project and map the individual requirement to a specific version.

3. Once a certain number of requirements have been assigned to corresponding JIRA projects, you can use the Create Issue link to launch a JIRA Issue Creation page. Assuming you also have a JIRA account and issue creation privilege for the project, you will notice a number of things:

The JIRA Issue Creation page is automatically associated with the project to which the Requirement was linked.
The issue is of type Task
The Issue Creation page is pre-filled with Summary and Description fields from the Requirement itself
The Issue Reporter is initialized to the person logged in
And more significantly, a custom field in JIRA showing links to "Related Requirements" has the originating requirement flagged.

At this point, all you have to do after clicking on the Create Issue link is to press the Create button on the issue creation page. The saved Task in JIRA will be automatically linked to the Requirement for which it was created.

And finally, the Requirements Document from where all this began will also automatically show the created JIRA Tasks, their corresponding Requirements, status, etc.

A simple use case but a very powerful paradigm for Enterprise Application Interoperability. All of this integration is driven by an underlying semantic infrastructure that maintains the relationship across the concepts that various tools represent.

You can Test-Drive this functionality in the sandbox for Teamwork.

-Sanjiva

PS - To test drive this feature, visit our sandbox

The screenshots below show the flow from Confluence Requirements Document page to JIRA Issue Creation page and back, reflecting the context that carries across the two applications automatically.

CAPTURE REQUIREMENTS AND ASSOCIATE WITH JIRA PROJECT(S)

AUTO-GENERATE PRE-FILLED JIRA ISSUE CREATION PAGE (WITH LINK TO INITIATING REQUIREMENT)

SAVE JIRA TASK (LINK TO INITIATING REQUIREMENT AUTOMATICALLY CAPTURED)

THE ORIGINATING REQUIREMENTS "DOCUMENT" IN CONFLUENCE AUTOMATICALLY UPDATES WITH NEWLY ASSIGNED TASKS

zAgile's Semantic Search - an OpenSocial gadget for Confluence and JIRA

2010-02-13T15:20:02-08:00

The support for OpenSocial gadgets in the latest releases of Atlassian's products (specifically JIRA 4.0 and Confluence 3.1) provides some interesting opportunities for creating dashboards as well as aggregating information into the application from external sources to enrich the overall information context.

This capability is even more relevant to us at zAgile because of the core premise of our platform of semantically integrating information from heterogeneous sources (tools) in a contextual manner to provide a more cohesive view. Hence, we have been exploring this capability within our solutions. One of the easiest and most intuitive is our implementation of Semantic Search. This functionality has been available in zAgile Teamwork from the very beginning, but now to implement it as an OpenSocial gadget made it portable, both within the applications as well as outside. Within JIRA and Confluence, gadgets can be placed anywhere, particularly for building various dashboards or views. Outside of JIRA and Confluence, OpenSocial gadgets can be incorporated into any compliant container. Once you have a unified information repository, then it is more compelling to be able to access that information from a variety of sources rather than resorting to specific container applications. This is where our platform comes in.

zAgile's Semantic Search has the following characteristics:

It accesses a single composite information repository which comprises of information from multiple sources, such as JIRA, Confluence (and soon) Subversion, CruiseControl, SalesForce, etc.
It is domain independent, driven solely by underlying ontologies and metamodels implemented as OWL-DL triple stores comprising of inferred and indexed models. Therefore,
1. It can search based on taxonomic structures (ex: searching for an Issue or a specific Issue type such as Bug, Task, etc.). Furthermore, you can also filter on specific properties (ex: search for a Jira Project that implements a specific Requirement).
2. It can search for inferred categories (a Person or an Author; an Issue or a Resolved Issue)
3. The results returned are of a specific category (specified in the search parameter) so you are not going to get anything that matches a particular search string. Search here is much more precise.
4. It also returns semantic properties of each instance in the result set (ex: project related to an issue, issue status, related requirement, related test cases, etc.)
5. It provides semantic (contextual) navigation to related items (from the issue navigate to its related project and project properties, from the project, navigate to project overview document, etc.) -- that without leaving the page or gadget.
6. Direct access to the resource - at any point during the search, you can go to the specific resource (issue screen, requirements page, etc.)

All of this is a manifestation of the semantically captured information from various sources. How powerful is this that you can view information from within Confluence that may actually be created by JIRA or SVN or any other tool, without needing to explicitly specify it on the page or even be aware of it. This begins to shift the pradigm from an application-centric environment to one that is more information-centric.

Finally, what if there are multiple Confluence or JIRA instances? Well, in this case, they all show up in a unified manner, and references to specific entities within these applications are captured so that navigation directly to the source is always available.

You can test drive the capabilities of zAgile's Smart Search (or Semantic Search) in the sandbox. A login is required with email validation and here you will find both Confluence and JIRA hosting this feature.

-Sanjiva

The screenshot below shows the results of a search for JIRA Projects in an OpenSocial gadget in a Confluence page. Project properties including related entities (such as Requirements, etc) are also shown along with drill down into one of the related entities.

A Big Deal for Small Teams

2009-10-07T12:22:13-07:00

Atlassian is now offering a great promotion of its highly popular toolset for software engineering teams (JIRA, Confluence, Fisheye, etc.) -- for a price of $10 each (proceeds go to Room to Read). For small engineering teams, this is a very exciting package since the tools included are full-featured and enterprise-class. We are also very excited to participate in this introductory offering for small teams, Now you can also get zAgile Teamwork for $10 for 10 users. zAgile Teamwork integrates and extends JIRA and Confluence to allow teams to use Confluence for Requirements and Test Case management and link them easily with Tasks and Projects in JIRA. Imagine -- the potential for achieving Requirements Traceability for only $10. For startups and small teams, this is a big deal.

-Sanjiva

Semantic Wikis in the Enterprise - Sanjiva Nath

2009-06-10T23:53:23-07:00

Semantic Wikis in the Enterprise - Sanjiva Nath

Shared via AddThis

zAgile @ '09 Semantic Technology Conference

2009-06-09T15:16:37-07:00

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

2009-04-22T10:11:58-07:00

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

2009-04-18T08:29:08-07:00

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

2009-04-12T10:48:04-07:00

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

2009-04-11T12:05:32-07:00

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

2009-04-08T20:58:59-07:00

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

2008-11-20T19:15:02-08:00

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:

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.
zAgile's ontology-based repository consisting of domain-specific ontologies (our current focus is on ontologies for software engineering)
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

2008-11-02T16:32:47-08:00

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

2008-11-01T15:27:55-07:00

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

2008-10-27T21:56:17-07:00

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

2008-10-16T14:51:57-07:00

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

2008-10-13T01:02:51-07:00

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

2008-10-12T02:36:39-07:00

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:

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.

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.

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

2008-07-05T20:50:36-07:00

"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

2008-07-05T18:49:29-07:00

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

2008-02-24T16:13:56-08:00

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

2008-01-25T20:19:05-08:00

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!!

2008-01-16T09:23:43-08:00

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 :)

2008-01-16T07:08:51-08:00

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

2007-11-21T22:08:39-08:00

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

2007-11-12T08:25:45-08:00

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!!

2007-05-11T15:40:57-07:00

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"

2007-05-11T04:05:56-07:00

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) !!

2007-05-02T01:18:13-07:00

Sanjiva Nath

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

2007-02-27T19:40:49-08:00

(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?

2006-12-12T09:14:25-08:00

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

2006-12-01T14:46:41-08:00

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.

http://www.zAgile.com

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

2006-08-18T23:33:16-07:00

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?

2006-03-29T23:44:02-08:00

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

2006-02-22T21:59:17-08:00

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:

A semantic substrate that is shared across applications, processes and business communities to leverage them effectively in various workflows and collaborations,
A pre-instantiated (out-of-the-box) offering of functionality from vendors rather than the 'toolkits' that they have continued to pitch
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