Modern Consulting vs. Classic Consulting: Part 4

No funny sub-title today; no, sir, it's right down to business!

Recap
The situation we're considering is as follows:

1. You are in charge of a large project to implement a new business process that is to be heavily automated.
2. You have a fixed budget and deadline.
3. You currently do not have the expertise or staff to undertake and complete the project.
4. You want to make as big (read: positive) an impression as possible.

We are in the middle of examining three different options in order to accomplish this project, as described in the original post in this series.

Again, this series is not meant to be exhaustive by any means; rather, it is an analysis by way of my experience in the consulting business for the past 11+ years.

Last time we looked at option 2 (i.e. what I consider to be a description of a classic consulting scenario).

Option 3 is on deck for this post, so let's get cracking!

Option 3

Find and contract a knowledgeable "one-stop shop" that has both the SMEs needed and the manpower to carry out the plan/advice from the SME(s).

Now we get to the option that combines the role of the consultant and the role of the development team.  What I mean is that instead of sourcing the consultant from one firm and the development from another (or, if you're going internal for development, the development from there), you source all those tasks from a single vendor.

One arrow means one source of responsibility.

We can see in this situation that you only need to deal with one vendor.  Once the vendor is found and contracted, no more time needs to be spent in finding the appropriate staff/contractors to implement your plan once you have it.

What's more, the vendor has a vested interest in coming up with a viable plan that not only can but must be executed, as the same vendor will be providing the development resources.  What good is the plan if the vendor's own resources can't implement it?  Dragging out projects for the sake of additional billing is a serious red flag for any consulting firm.

The vendor is also more likely to be more flexible and accommodating for scope changes (let's face it: they do happen) than having a separate vendor for each purpose (as in option 2).

Project Management and Documentation

(This is a slight aside, but one worth mentioning.)

Often times, the vendor will assign a Project Manager or account liaison to work with you to complete your project.

If there's one piece of advice I can give with respect to having a PM, it's that they are worth paying for.

It's a common occurrence for clients to want to save money by reducing the number of line items and resources as much as possible.  Project management and project documentation are often the first things to go.  Do not give in to this temptation.  A vendor worth its salt will happily walk you through the benefits of having a project manager (as well as having proper documentation, both technical and otherwise).

Vendor Confidence

One argument that is sometimes made is that the client does not want to put all his/her eggs into one basket, so to speak.

I can understand some of the concern in this ("What if the company goes under?" "Will they be transparent enough in their internal interactions?" Etc.).  However, in my professional opinion, in the vast majority of cases, the benefits far outweigh the concerns.

A good way for you to vet the vendor is to investigate any references/testimonials they have (if none are readily available via their website or other means, don't be afraid to ask the vendor for some).  Due diligence is something you should always engage in, regardless.

As a slight aside, look for an honest vendor, and by that I mean one that won't say "yes" to absolutely everything (irrespective of data) and one that won't try to say "it can't be done" whenever you suggest a certain approach.  Consulting is largely about developing a relationship with the client and sharing in the risks and success of the project.

No, not THESE Yes men.

(Again, any such vendor worth its salt will anticipate these concerns and address each one with you.  Your peace of mind should be on the top of their priority list when it comes to dealing with you.)

Rates

It's also possible that the vendor will give a bit of a break on the rate given that you're engaging them not just for consulting/planning work, but for development work, as well.  More hours usually means a greater incentive to keep you, the client, happy.

You might pay a bit more for the lead consultant, but it likely won't be as much as it would have been from a classic consulting firm, and the development resources' rates will likely be less than the lead consultant's.

Also remember that you get what you pay for: Be way of firms that offer development work for $20/hour.  I've never been one for outsourcing, so please don't tell me about sending out your work for $1/hour for a team of 10 developers (I know the likely outcome of those stories).

Who Does the Work?

In most situations, the person performing the consulting should not be the only one doing the development work (this has been known to happen in smaller firms, but outside of smaller projects, this usually doesn't work out so well).  In fact, the consultant should likely not be performing any development in order to remain objective, available, and to "see the forest for the trees".

Pros and Cons

So let's list the pros and cons for option 3:

Pros

1. Time spent acting as an intermediary between the consultant and the dev team is minimized.  Your time (and your team's time) is important.
2. Time is saved not needing to find/contract both a consultant and a separate development team.
3. Greater/enhanced communication between the consultant and the dev team, thereby bypassing/reducing potential miscommunication.
4. Increased likelihood of successful plan implementation.
5. Greater flexibility during both planning and execution phases.
6. Reduced chance of budget and time overrun.
7. The chance of getting a break on rate is higher (though not guaranteed).
8. Greater perceived value, in addition to greater actual value (i.e. you're not just getting a document that "passes the weight test".)

Cons

1. Potential "eggs in one basket" situation.
2. Can be challenging to find a vendor that has both the domain expertise and development expertise together in one shop if you don't know where to look.
3. May sacrifice laser-like competency and depth in a particular field for something more akin to a carbide drill or even an entire workshop (think about it).
4. Increased need for vendor transparency (but this is easily addressed).

Unlike the previous two options, the pros far outnumber the cons.  

This option holds many advantages that address the concerns raised with option 2.

Synopsis

We see here an outline of what I refer to as a modern consulting situation; in other words, the vendor/consulting firm provides a "one-stop shop" for all of your project's needs.  This greatly simplifies matters and streamlines them, especially when you have a technical need such as the one described in this thought experiment.

The value here should be obvious, and while it's not always the right tool for the job, in most technical situations, it is (even in non-technical matters, having the consultant get their hands dirty with plan implementation can be beneficial in a lot of situations).

Yes, consulting is a "noble profession" (as Dr. Weiss puts it), but I believe that the definition of what consultants need to do--especially with respect to the ever-growing need for technical expertise--needs to evolve beyond just writing a plan.

I've come across more than a few consulting firms who do nothing more than produce reams of documentation for a plan that spans hundreds of pages, only to never see the light of day again.  To me, that's not only not adding any value, it's costing a business money and can even become a liability, and that's never acceptable.

Next Time...

...we'll wrap things up with a conclusion to this whole thought experiment and bring it back full circle to where the first post started.

(From Disney's The Lion King)

It's kind of like the circle of life that way <cue Elton John music>.

See you on the next post!

Modern Consulting vs. Classic Consulting: Part 3 (or, The One with the Unexciting Title)

Welcome to part three of my continuing series comparing classic consulting with modern consulting!

We continue the thought exercise introduced in previous posts to investigate the differences between classic and modern consulting.

In this post, we'll be looking at a different option than the one we looked at in the last post in order to address the given situation.

What is that situation, you ask?  That's a great segue for the...

Wrong Segway(tm)!

Recap
The situation we're considering is as follows:

1. You are in charge of a large project to implement a new business process that is to be heavily automated.
2. You have a fixed budget and deadline.
3. You currently do not have the expertise or staff to undertake and complete the project.
4. You want to make as big (read: positive) an impression as possible.

We are in the middle of examining three different options in order to accomplish this project, as described in the original post in this series.

Again, this series is not meant to be exhaustive by any means; rather, it is an analysis by way of my experience in the consulting business for the past 11+ years.

Last time we looked at option 1 (i.e. doing everything internally).

Today we're going to look at option 2!

Option 2

Find and contract a knowledgeable consultant to advise on the project and then either field a staff to implement or contract out the work to another firm.

This is a typical fit for the classic consultant.  They're likely going to charge a sizable sum, but depending on what they actually deliver (or, sometimes, don't deliver), it can be worth it.  The peace of mind that comes with a well thought out plan that you can implement can be invaluable, but actually having a roadmap or plan that can be followed and you can rely on is where the real value is added.

Provided the consultant is genuinely interested in providing value (a trait Peter Block refers to as "being authentic"), you can hit the ground running with the project, save time in getting started, save money from not sinking money and carrying costs into hiring as many people as you would otherwise need, and be assured you have a solid approach.

Of course this all presupposes that you end up accepting and taking the consultant's advice.  Most times, however, barring some other pressures/circumstances, you likely will.

However.

Now you are left with the task of actually putting the consultant's plan/advice in motion.

1. Do you go a similar route as option 1 and field the staff necessary to implement the plan?
2. Do you contract out the work to another firm that specializes in development?

We've already examined the first possibility as part of option 1, so we're well aware of the costs in terms of time and money (and other considerations) that would need to be looked at in order to carry out this plan.

So let's look at the second possibility.

• You will need lead time to find a vendor that best suits your needs (unless, of course, you have a vendor of record for such tasks).  This is likely to be shorter than the time needed to screen for internal staff.
• Time will have to be spent so the vendor can gather requirements and you can share the plan you're working to implement.  This will likely take about the same amount of time as if you were working with your own internal staff (and provided that they are also utilizing best practices and processes, which they should be; if the vendor isn't, then that's a serious red flag).
• You may well save time in development if the vendor is quite experienced as you can be assured their project staff and developers are proven and seasoned.  An internal staff might take longer to suss out in terms of these same qualities.
• There is a single "throat to choke" and, God forbid, if things really go pear shaped, you can likely recuperate some of the cost (remember your goals from the first post in this series?).  We all know bosses who are impressed by the timeless art of "grinding".
• The hourly cost of such a vendor are most likely going to be higher than that of an internal staff, but keep in mind you're no longer carrying much of the overhead, and you can engage them for a fixed length of time.

There look to be some real benefits in pursuing this model!

(Courtesy of: general-data.com)

Hopefully it's just a figurative approach.

But what happens if the plan hits a hiccup or isn't as rock-solid as we had initially thought and signed off on?

What happens if there are questions about the plan?  Is there a support contract in place?

Does the consultant have time to accommodate your schedule if he/she is really busy?

And I promise you: There will be questions after the fact, no matter how flexible the plan is (in fact, you may find that the more flexible the plan is, the more questions that will arise down the road).

You're likely to find that questions/consultations "after the fact" are going to be costly, both in terms of the consultants hourly cost and in terms of time spent doing back-and forth between the consultant and the development team.  (If you want to get the consultant and the dev team talking to each other, not only do you have to pay for both their time, but you have to ensure their discussions are productive and accountable.)

The potential for miscommunication here is manageable, but noticeable.

Let's review the pros and cons of this option, shall we?

Pros

1. A solid roadmap that can be used to guide the implementation of your project and help ensure its success.
2. Quick to "hit the ground running" for getting the project started.
3. Very likely going to cost less over the lifespan of the project (see the caveats above).
4. Accountability from vendors.

Cons

1. After you have the plan, additional questions and consultations with the consultant will cost (probably by the hour).  If the consultant is busy, finding time to schedule you in might not work with your own schedule.
2. Time spent in back-and-forth between the consultant, yourself, and/or the development team can cause frustration, lost time, and additional financial costs.  (This is what I like to call a real "time vampire").
3. If the development team decides to take liberties/assumptions with the plan given, because they might not have the insight that the consultant has, it could subtly steer the project in a direction slight off-target.  Enough of these "liberties" can derail a project entirely if left unchecked.
4. If things do go wrong, the blame game makes a serious appearance.  Who's to blame?  The consultant?  The development team?  Some combination thereof, and if so, how do you address the issue?  If this does happen (and it can/will), you will spend a lot of time running around between the two sides to get to the bottom of the issue.  It's not an A&E-type of situation (i.e. that's not exactly time well spent).

It's clear to see that this option immediately seems at least a bit more appealing than the previous one.  Gone is a lot of the time spent before the actual project can get moving, as well as a good portion of the overhead costs.

Things could still be improved upon, though.

Synopsis

This option is a traditional scenario for many projects of varying sizes.  It clearly helps mitigate time and costs while helping to ensure a successful project.

It also outlines what I refer to as a classic consulting situation; that is, the consultant offers advice only and no further services.

The largest concern coming out of this option is the disconnect and/or lack of direct contact between the consultant and the development team.  The project can still succeed, but we put at risk the projected cost (i.e. we're likely not minimizing our projected expenditure as much as we could) as well as the quality of the work (miscommunication and "broken telephone" can easily make a project suffer).

Next Time...

...we'll address this concern in the next post of this series as we look at what I consider to be an example of a modern consulting solution, which can add considerable value to a project such as this one.

Modern Consulting vs. Classic Consulting: The Sequel!

Previously, on the Mad Grapher

(Or maybe I should start off with "today, on a very special Mad Grapher..."

Ah, the things you can get away with on the internet!  But really, every post on this blog is very special!  And not in a patronizing kind of way, either.)

Last time, I described BHS Consultants as an "IT/technology consulting firm".  I also stated that it's a bit of a challenging label for the business.

In this post, we'll continue investigating the differences between what I call "classic consulting" and "modern consulting" by way of a (fairly short) thought exercise.

Recap

The situation we're considering is as follows:

1. You are in charge of a large project to implement a new business process that is to be heavily automated.
2. You have a fixed budget and deadline.
3. You currently do not have the expertise or staff to undertake and complete the project.
4. You want to make as big (read: positive) an impression as possible.

We are going to consider three options to accomplish this, as described in the previous post.

Let's start with option 1 (seems to be the most logical starting point).

Option 1

Find and take on an internal staff (either full-time or contract) including both SMEs (Subject Matter Experts) and implementors.

If you've ever had to hire and grow a staff, you know that it takes time to field the right people for the team--a long time.  Time, effort and money has to be spent tracking down those people (job postings, recruiters, etc.), not to mention screening and managing them (sure, you could always hire managers--and you'll probably have to for a sizable project--but that's yet another line item in your budget).  Headhunters can also charge a small fortune and their success rate varies at the best of time.  Tack on to that annual salaries, the cost of benefits, vacation days, sick days, turnover, etc. ad nauseum.

Yes, you'll likely have a greater degree of influence and control (some will also argue that your employees will "care" more and are more likely to provide buy-in; I don't necessarily agree with that point), but you'll have a lot of extra costs to carry (even for contracted employees which have similar costs associated with them).

If your office infrastructure is anywhere near capacity (or even if it's running at an optimum rate), adjusting for an influx of staff can add serious costs here, too.  

So on top of the pressure to complete your project, you have the added pressure (and time and cost) in hiring your own staff.

(From 20th Century Fox's Office Space)

Plus you might end up with this guy.  Poor Milton...

Let's summarize what we've seen with this option:

Pros

1. Greater control and influence over resources.
2. Possibly greater buy-in/"caring" for the project and its success by your resources.
3. Makes some degree of sense for longer-term projects that require ongoing support.

Cons

1. Lead time and spin-up time to get the team fully staffed and firing on all cylinders.
2. Significant overhead costs.
3. Dealing with HR-related issues (sick days, turnover, etc.).
4. Possible infrastructure costs to accommodate new/growing staff.

I state point #3 in the "Pros" section because it does hold some water; however, this can be a difficult determination to make without doing some analysis in terms of the projected lifespan of the project (and its support) versus the cost of upkeep.

Synopsis

For companies engaging in longer-term projects that are close to its set of core competencies, this option does hold some merit.  But in an ongoing attempt at trying to improve bottom-lines everywhere (not to mention meet ever-tightening deadlines often created by the impression that technology magically speeds everything up), this option isn't as attractive as it once used to be.

Option 1 is a typical situation where a consultant will try to introduce himself/herself to help advise and guide the project along in the attempt to make the process as smooth as possible.  We'll see in the coming posts how a consulting firm engaging in modern consulting compares to the firm engaging in more traditional classic consulting.

Next Time...

...we'll investigate Option 2 where we see how a classic consultant would improve upon Option 1.

See you next time!

Modern Consulting vs. Classic Consulting: Part 1

Welcome back, all you graphanatics (oooh, I like that term; think I'll use it more, even though this post isn't about graphs)!

In my last post, I'd mentioned that BHS Consultants is an "IT/technology consulting firm"; I also mentioned that I'd discuss why this is a challenging label for a company such as ours.

Over the next couple posts, I'll be taking you through a more detailed examination of why that label is a challenging one for our company by way of comparing and contrasting what I call "classic consulting" and "modern consulting".

(I fully expect some people to disagree, and, as always, I welcome any/all constructive feedback and opinions.)

Classic Consulting

Classic consulting typically consists of offering expert knowledge to those companies that need to improve/implement a process, reduce/eliminate existing problems and challenges, and/or otherwise lend guidance to expertly guide a project.

Notice the emphasis on process and advice; there is no actual implementation work or "getting your hands dirty" in that respect.  (Peter Block, author of Flawless Consulting long-time consultant, hammers this point home in his book.)

Now I'm sure some (if not many) out there will either take exception or outright disagree with my definition above, and that's fine.  It lends credence to the fact that even classic consulting is a difficult animal to clearly define.

There's also the associated stigma that has traditionally been associated with the business of consulting.

We've all heard this one before.

And believe me, I've come across my fair share of other consultants that would do little but state the obvious and prolong any problem/contract for as long as they could in order to bill for more hours.

Personally (and professionally), I believe if you're not adding significant value as a consultant, then you have no place doing the job.

"Modern" Consulting

Not to be confused with Activision's Modern Warfare video game series.

In his book The Consulting Bible: Everything You Need to Know to Create and Expand a Seven-Figure Consulting Practice, Dr. Alan Weiss (a very successful consultant in his own right) states--for all intents and purposes--that consulting is a "noble" profession and if you're another set of hands helping on a project (again, actually "getting your hands dirty" with implementation), then you're not a real consultant.

So we now have two authors and extremely successful consultants who have clearly stated their definition of what consulting is (and is not).

I'm going to rock the boat a bit here and say the following:

Modern consulting has adapted to meet the increasing demands of clients and must continue to do so in order to remain relevant and useful.

To be clear, I'm not saying that the principles and hallmarks of classic consulting are moot and no longer relevant; far from it, in fact.  Modern consulting builds off much of the foundation of classic consulting.  In essence, modern consulting expands the purview of classic consulting and removes many of the traditional boundaries between advising clients and actually performing implementation.

At the heart of consulting, to be sure, as many experts have written (including both Mr. Block and Dr. Weiss), is to have your advice actually used.


This definition of modern consulting is especially true in the field of IT and other technology-based fields (of which there are an ever-increasing number).

Consider this: You're put in charge of a large project to implement a new internal business process that is to be heavily automated, and you (and your superiors) know that no one in the organization has the know-how or experience to approach this project on his/her own, let alone the manpower to actually carry out the implementation.  What's more is that you're given a deadline (as is usually the case; how far in the future the deadline is doesn't factor in) and a budget (as is also usually the case).

As the person in charge of this project, you clearly want to do the job well and make a big impression on your superiors (there could be a bonus, a raise, or a promotion in it for you).

The best way to make such an impression is to achieve the following goals:

1. Complete the project on-time.
2. Complete the project within (and preferably well under) the budget.
3. Complete the project with a high degree of quality.

(In my experience, in the worst case, if such a person can only achieve one of those goals, it'll usually be #2 as it's easier to make a good impression when you're able to point to a contribution to the bottom-line.  This is unfortunate, but sometimes necessary and it does happen more frequently than it should; remember, as consultant--classic or modern--your job is to get your client to listen to you.  If they don't, then there's little you can do about it, and you have to be prepared to accept that.)

I think we're all familiar with this model.

So, you have choices--some of them less desirable/applicable than others.

1. Find and take on an internal staff (either full-time or contract) including both SMEs (Subject Matter Experts) and implementors.
2. Find and contract a knowledgeable consultant to advise on the project and then either field a staff to implement or contract out the work to another firm.
3. Find and contract a knowledgeable "one-stop shop" that has both the SMEs needed and the manpower to carry out the plan/advice from the SME(s).

There may be more options, but these are traditionally the three decision-makers and senior managers are faced with.

Next Time...

In the next post, we'll examine these three options in more detail.

(If my blog had a cool "Next Time, on the Mad Grapher" teaser trailer, I'd insert it right here.)

See you next time!

A Re-Introduction of Sorts

Ok, I'm back for real this time.  I apologize for my hiatus but sometimes work gets the better of you.  I've been spending my days meeting deadlines, attending sales meetings, reviewing internal numbers, and all the good stuff that comes along with my job.  It then dawned on me late last night that I hadn't posted on here in nearly two months!  Yikes!

Time to fix that.

It's funny; I work for a small IT/technology consulting firm (I'll go into why this is a challenging "label" for the company in my next post) that's been around for nearly 20 years.  In my position, I should know that regular self-marketing is crucial to growing business.  As many of you know, I'm sure, it can be very easy to forget about that and slip into the day-to-day routine of managing and running your company.

"Now hold on a minute!  Where are the posts related to graph databases?" the astute reader will immediately wonder.

My answer is similar to the one given above: It's been difficult to clear time for myself to further investigate my beloved graph databases; however, I'm going to try to make a conscious effort in the coming months to reverse that.

So, I'm expanding the scope of this blog to include matters that involve what I hope to be beneficial information and insight into my industry.

I am the CIO and VP, Technology of BHS Consultants.  I've been with the company since 2001 and started as a junior developer and co-op student.  Technology moves fast, and those who work in/with it have to move fast, as well.

It's my goal to pass on the insight and knowledge I've gained over the years in addition to the new things I come across and learn in my travels.

Some of it may be conventional wisdom; some of it may fly in the face of it.  I leave it as an exercise to the reader (I've always wanted to use that phrase ever since university) to think critically about what I put forward and take from it what you will, whether you agree or disagree with what you read.

That's a long enough re-introduction.  I hope to post a lot more to this blog, both on technology and business alike.

Comments, as always, are always welcome (please do try to keep them constructive, though).

I'll see you on the next post!

Still Here! Kinda...

Hey all!

  Ok, it's been awhile.  Work is occupying most of my free time (go figure), even as I look out the window and see the 20C+ weather outside!  Sigh.

  I hope to get back at this sometime soon.

  The one cool thing I've been looking into (that I've overlooked in years past) is Google's annual Code Jam contest.  I've been going through the practice problems and actually faring all right (I'd say about an 80-90% success rate), which, for me, is making me feel pretty awesome as I've been out of school for some 7-8 years now (yes, the problems do make you feel like you're in school sometimes; is that good or bad?).

  I strongly suggest checking it out and even trying out some of the practice problems, if for no other reason than to keep your coding and problem solving skills in shape (you can use any language that has a "free" compiler; my weapon of choice is C++ with the good ol' STL using g++).

  If you feel so inclined, drop me a line with your thoughts on some of the problems.  Pay close attention to those problems that are of a graphing nature (determining appropriate data structures to represent graphs is always a great exercise!).  Makes you wonder if something like neo4j would help out (though, there's still the question of developing the actual algorithms, but maybe the canned ones like A*, Dijkstra, etc. can be leveraged, too...interesting.)...

  Ok all, enjoy the not-so-lousy Smarch weather!

  See you next time!

  

Fun with Gremlin (not related to the movie or the car))

So you have all of this graph-tacular data in your graph database (for this post, I'm using neo4j).  It looks slick with its vertices and edges.  People stop by your desk to say, "Is that the new connect-the-dots app you're working on?"

After staring at them for a couple moments and repressing the urge to sell them the "app" for five bucks, you start thinking about how you're going to access and use this wonderful data.

"If only there was a way to query the data..." you wonder.

While SQL is the querying language of choice for relational databases, there is no real "standard" as far as NoSQL databases go (that's a subject for another time).

In the world of graph-driven databases, there are options:

• Gremlin; a Groovy-based querying language that can handle any type of query.  This language is perhaps geared more towards those with more of a math- or graph-based background as the syntax is nothing like SQL.
• SPARQL; a popular query language for RDF graphs.  This language is likely more easily picked up by those with an SQL background as the syntax is more SQL-like than Gremlin.
• Cypher; a neo4j-specific querying language.  This language currently only allows read-only queries of graphs (i.e. no inserts, updates or deletions).  Like SPARQL, Cypher also takes its cues from SQL.

Neo4j folks: At the time of this writing, neo4j comes pre-loaded with plugins for both Gremlin and Cypher.  (As I understand things, there is currently a ticket open in the neo4j community to develop a SPARQL plugin, but has not yet been completed; there are likely complications stemming from the fact that neo4j is not an RDF database at its core.)

In this article, I'm going to cover some basics in using Gremlin.  By using some concrete examples, I hope to demonstrate a bit of the power behind using a graph-based database!

For the purposes of this post, I'll be making use of a small graph I created that contains some people, who they know, and what they've purchased.  I expect this graph to grow and change as time goes on, but, that's where it stands for now (this is the beauty of schema-less data).

So far, Gremlin is the only querying language I've used with graph databases, hence this article making use of Gremlin.  The good thing about this Gremlin is that it won't require a new muffler and you don't have to worry about feeding it after midnight.

Getting started with Gremlin and Neo4j is easy enough.  It's a plugin that comes with Neo4j, so all you need to do to begin is to open up your Neo4j web admin instance, click the "Console" menu option at the top, and select the "Gremlin" option from the top-right of the console that appears.

At this point, you're faced with the currently-available variables and a gremlin overlooking them, like so:

We see that the variable g contains the current graph.  If we issue the query "g.V" (without the quotes, as always), we get a list of all the vertices (nodes) in the graph; however, this information is not incredibly useful as you're only given each node's ID.

Let's say some (but not all) of our nodes have been given the property "Name".  If we try using "g.V.Name", we'll again see a listing of the nodes; however, the value of the "Name" property for each node (if available) will appear (if "Name" isn't a property of a specific node, "null" will appear; also, note that Gremlin is case-sensitive).

We can also similarly view a list of the edges (relationships) by issuing "g.E" to the console; this time, however, in addition to the edge IDs, we also see the type of relationship and the adjoining vertices (nodes), e.g. 1-KNOWS->6.  Note that you can see that these edges are directed!  In this case, we see that the edge goes out from node 1 and goes in to node 6.  Useful stuff.

We can also (similarly) view a property of the edges (if it exists) as we did for the vertices, e.g. "g.E.Quantity".

Identifying individual vertices and edges is simply a matter of knowing each one's ID number.  Obtaining a reference to a node (which, yes, can be assigned to variables for easier reference) involves a call like "g.v(6)" or "g.e(3)" (note the casing).

You can examine the value of an individual node's/relationship's specific property by querying it much like we did above, e.g. "g.v(6).Name".

Want to know all of the edges coming out of a node?  "g.v(6).outE" will do the trick.  Similarly, if you want to know all of the edges coming in to a node, we can use "g.v(6).inE".

We can also go one step further and use the "inV" and "outV" steps to identify the nodes on the ends of edge.  "inV" will correspond to the node at the head of an edge (also known as the "incoming vertex"), whereas "outV" will correspond to the other side of an edge (an "outgoing vertex").

You can also use "bothV" and "bothE" to get both incoming and outoing vertices and edges (respectively).

So if you want to travel from one node to another, you might do something like: v(1).outE.inV.  You can shorten this by using: v(1).out.  There exist similar constructs for "in" and "both". (Note that for "in", it's a short-cut for "inE.outV".)

Have more than one relationship connecting a node?  No problem!  You can access specific ones via something like this: v(1).out('LIKES') (this will take you to the node on the other end of the 'LIKES' relationship for node v(1)).

(Gremlin's github page has a good basic tutorial about all this.)

I could go on at great length about the features of Gremlin, but I think this is a great starting point.  I'm going to include some concrete examples below.  If I use any constructs or syntax that doesn't make sense, I very much encourage you to visit the Gremlin wiki page to look up the answers; this is a good little exercise, especially for the "groupCount" and "cap" constructs.

The graph below assumes one that has nodes describing products and people, and has relationships showing purchases and who knows whom.

How many times has each product been purchased?

g.V.inE('PURCHASED').inV.ProductType.groupCount.cap

Which products have been purchased more than once?

g.V.filter{it.inE('PURCHASED').count() > 1}.ProductType

Who is known by more than one person in this graph (we define 'knowing' as sharing an edge/relationship--in or out--with another person)?

g.V.filter{it.bothE('KNOWS').count() > 1}.Name

Who knows the most people, and how many people do they know?

g.V.bothE('KNOWS').outV.Name.groupCount.cap

How well-known is each person?

g.V.both('KNOWS').Name.groupCount.cap

(By the way, if anyone notices anything wrong with anything above, please let me know as I'm always looking to evolve and develop my knowledge of, well, everything.)

So you begin to see the power of what we can extract out of a graph database!  Personally, I'm tempted to find out "who is your daddy and what does he do?"  Such a question would be relatively straight-forward to figure out!

Ok, I think that's enough for now.  Hopefully this is a decent (but brief) introduction to the world of Gremlin and querying graph databases.  I know writing this has forced me to examine in more depth exactly what exactly these queries actually do.

I'll see you next time!