Someone had to do it, and I’m glad it was Theo Priestley, and not I!

Theo’s written up a summary of the Forrester-initiated BPM Jam on Twitter (thanks Connie!), and did a pretty good job of it.

Key points from his summary, where the idea that education needs to standardize (a la ABPMP), but also needs a more mature, comprehensive approach (a la Lombardi University). I missed this part of the discussion so I’m not sure how people felt about the OMG OCEB examination – of course, since that is a cert only, not a full educational curriculum, that may be why it was overlooked.

Another key point was the idea that a business architect requires 20 yrs of experience with Six Sigma, Lean, TQM under the belt.  As Theo put it:

I disagree somewhat on that point, whilst those methods are ‘nice to haves’ they shouldn’t be prerequisites of a Biz Arch and certainly not as steeped in the skills that they can’t accept outside influences. I’ve seen this among a lot of Master Black Belts and I don’t think they have what it takes to be a Biz Arch on this alone. Needs to be cross-skilled and understand architecture on a wider scale outside of process alone.

I think the key point Theo makes is that if you have adopted the religion of Six Sigma, or Lean or <fill-in-your-favorite-improvement-methodology>, you may be too inflexible to solve BPM problems in the most effective way.  A simple example I’ve seen of this is the Lean and Six Sigma ideal of ignoring technology while improving the process.  As with most doctrines, there is a kernel of a good idea there, but too often it is taken too far – to the point where many six sigma and Lean practitioners seem to be saying that technology can’t inform process improvement approaches – which any software engineer can disprove.  The real point of course is to not let technology slow down the process improvement, which is a very different thing altogether, and something I very much agree with.

Good article from Connie Moore of Forrester yesterday, on assessing the BPM market the day after the Savvion news broke.

As she points out, these deals are important because of:

• Convergence of BPM types
• Clear signs of expanded interest in BPM by big players
• Closer integration of several business technologies (BPMS, BAI, etc.)
• Better BPMS from IBM
• More acquisitions and consolidation to come

Connie goes on to give her impressions of Pega, Appian, and other pure plays and innovators.

Like Connie, I think there’s still a lot of room for innovation in the market as the creative-destructive capitalistic processes continue.  She also took time to point out that many of the acquirers do not understand that there is more to BPM than software- there is a methodology and discipline of continuous improvement that most software vendors simply don’t have, and don’t appreciate (at least, as it pertains to their customer engagements – they may very well practice continuous improvement inside their own organization). I think this acquisition activity is going to put further demands on service companies to bridge the gap.

There was a post over on Lombardi’s “Process People” blog referencing all the events they’ve attended in the Fall of 2009, from Gartner BPM Summit to Forrester’s BTF to the Gartner ITxpo. Event schedules have wound down for 2009… but its a great time to start planning to attend bpmCamp on January 28-29, 2010!

Background: BPM Conferences Are Good…
Conferences are a great way for colleagues and peers to network, share best practices, and re-energize and re-motivate their efforts.  In particular we’ve enjoyed participating and presenting at Lombardi’s Driven conferences in the past, and at bp3 we’ve attended Lombardi Driven, Appian’s conference, OMG’s Thinktank, Gartner BPM, and Forrester BPM conferences (when we weren’t too busy with customers).  Conferences have some of the value of an off-site meeting within the company: recharging the batteries and motivating action.  But they also provide a chance to be exposed to much more diverse points of view, to out-of-the-box thinking, to new tricks of the trade, and to new market dynamics.  In smaller conferences, or small breakout sessions, real discussions break out that can really be illuminating (OMG’s Round Table format is a well-known example of formalizing this kind of small-discussion format, and it led to the six barriers to BPM Adoption at a very humorous and educational round table that I was fortunate to attend).

…but Missing the Mark.
There are just a couple of problems.  First, conferences run by Analyst firms and Conference organizers are often too expensive (especially with today’s budgets).  Second, vendor conferences are too focused on the sponsoring vendor’s messaging, and often neglect the real needs of attendees. Attendees to both types of conferences get value, but I often hear them expressing an interest in getting into more detail – moving past concept to tactics.  Moving past platitudes to showing real solutions.

Its our belief that it is just too hard to get into the specifics and details in a multi-vendor conference.  Even with respect to project methodology, the *right* approach to a project has to take into account the realities of the technology being used.  If you’re using a BPM tool that doesn’t provide rapid UI prototyping, you’ll need a different approach to your project than someone using a BPM tool that does provide rapid UI prototyping.  And that’s just one trivial example.  When we get down to sharing technical best practices, going cross-vendor just doesn’t make much sense- BPM execution level detail simply isn’t that portable.

…So What’s the Answer?
If we put together a conference that is focused on what attendees want to talk about, we’ll get more value for the dollar.  If we aren’t looking to clear a profit on the event, we can lower the investment barrier required to attend.  If we focus on a single vendor, we can focus all the way down to shared source code if it has value. To that end, we’re going to borrow from concepts pioneered by unconferences and barCamps, leveraging advice from folks who put on the SXSWi barcamp in the past.

With preamble aside, I’m very happy to announce what I believe to be a first:  a BPM unconference for BPM practitioners of a single product suite.  We’re calling it bpmCamp.

This first event is focused on users of Lombardi’s Teamworks or Blueprint products.  We’re focusing on this community because it is the set of products and practitioner community that we have the deepest connections into, and because we want the event to be a single BPM product event for the reasons stated above.

Why bpmCamp?

We really think the BPM community/ecosystem needs events like this to foster growth, success, and maturity.  We believe maturity requires:

• technical breadth and depth
• project methodologies to support the roll-out of processes and improvements to those processes
• process improvement techniques and strategies that can actually be implemented and maintained in BPM suites

Also, we actually want to learn something new.  When we get the right  practitioners in a room, we’re going to learn from them, and help propagate those best practices into the BPM ecosystem.  We’re also going to share what we know from prior experience directly with the conference.  This cross-pollination is good for everyone.

Finally, we decided to put action behind our words.  We’ve long agitated politely for more tactical, focused topics at BPM conferences, but we’ve reached the point where it is time for us to contribute back to the community by creating an intimate event that fosters that kind of discussion.

When is bpmCamp?

We’ve selected a date for the first one:  January 28-29, 2010. Mark your calendars.

We hope to host additional bpmCamp events in the future, but this is the inaugural event, and it should be special.  Please watch this blog as we’ll put up an F.A.Q. as soon as tomorrow with more details.

If you have any questions in the meantime, contact us at:
bpmCamp Email: 

(editor’s note: bpmCamp is not affiliated with or sponsored by Lombardi.  bp3 is not acting on Lombardi’s behalf, nor is bp3 an affiliate nor subsidiary of Lombardi. )

In a Forrester blog that usually focuses on more “process” and “application” issues, Claire Schooley recently blogged about Telepresence and Video Collaboration.  It might seem a little off-topic, but we at BP3 have written a few posts about video conferencing ourselves (here and here), because we’re fans of the technology (and in particular, of the solution we use from Lifesize). And in fact, good video collaboration may be a key to more efficient business processes in the future.

What Schooley describes is the expensive high-end solution, with purpose-built-and-equipped rooms.  However, most of the same benefits can be achieved with less expensive solutions from a firm like Lifesize: high definition video, high-quality full duplex audio, IP-connectivity, and interoperability with standards that enable cross-vendor calls (with, for example, Polycom and Tandberg).

When friends ask me about our video conferencing setup, I often tell them if I could get the cost down to $1000 per location, we’d have a system in every office – because it is worth that much to us.  The high-fidelity connections are just better than a skype video chat (though that is certainly better than nothing!).  The price keeps getting closer – LifeSize just came out with a unit that brings the price down to approximately $2500, and then with the Desktop solution there’s a bit lower-fidelity option that’s even cheaper.

I don’t think it won’t be long before the quick trip on an airplane for a meeting will be a memory (or a luxury), but before that happens, we need to get high fidelity videoconferencing to be nearly as ubiquitous as instant messaging.

Ok.  Forrester didn’t really say that.  But in Ted Schadler’s article “The State of US Workforce Technology Adoption“, point #4 says practically that:

Gen Y employees are getting squashed at work.These younger workers behave very differently from others outside of work, but they are not so different in how they use technology in their jobs. Sixty percent of these 18- to 29-year-olds use social networking at home, but only 13% use it for work — the same percentage as Gen X employees ages 30 to 43.

I wouldn’t have said squashed.  That’s a characterization based on the assumption that Gen Y uses more technology than Gen X.  But only 13% use these social networking tools at work.  For all the carping I’ve heard about Gen Y using Facebook at work, one our own Gen Y members recently told me he quit using Facebook entirely and doesn’t miss it.  My personal theory:  like everyone else, Gen Y folks value real relationships more than virtual ones and eventually everyone finds a balance.  And at the end of the day, there’s work to get done.

Maybe, someday soon, we can stop this “generational” management stuff and get back to work.  But sure as I say that, Fortune will coin a term for the next generation.

Forrester makes some additional points that are worth noting:

There is pent up demand for smartphones. Only one in 10 information workers has a smartphone for work, but one in three agrees that they use a personal mobile phone for work purposes. Twenty-one percent of iWorkers would like to get email outside of work, and 15% would like email on a smartphone. Any way you slice it, this means that there is pent-up demand for smartphones at work.

It is amazing to me that still only 1 in 10 information workers has a smartphone for work.  Even more amazing: over the last couple of years I’ve seen Fortune 500 companies pull back their subsidies for smart-phones for work – essentially cutting off their information workers from company information during off-hours (and work hours while not at their desks).  The benefits of that connectivity confer primarily on the corporation, not on the employee, but apparently these firms felt that the costs outweighed the benefits.  In our business, we make sure that everyone has a smart phone.

In another note, Forrester points out that collaboration tools are stalling out – leaving email as (still) the primary collaboration platform.   Of course, this makes sense: everyone has email, even if they don’t use your particular email platform.  The standards for email are well-established and widespread.  But to use a collaboration platform, we have to ALL use the same collaboration platform.  For those who have received early invites to Google’s Wave, I’m sure you can relate:  being early into the collaboration platform is like having Instant Messaging with no one in your contact list.  Who exactly are you going to collaborate with?

This could mean that collaboration tools that leverage email will have an edge over new platforms.  It also means that collaboration tools that suit a particular niche (Business Process Modeling for example) are more likely to draw the appropriate audience than generic collaboration tools.

UPDATE 10/22: I just read this article about Gen Y preferring to keep email over social networks, and it just sounds like more confirmation to me of what I already believed- the generations aren’t fundamentally different in big swaths of people as the media prefers to portray them – the labels are a convenience and contrivance to talk about people “of a certain age” without specifying exactly what that age is.  There are some questions on the validity of the study, but it is still a reflection of the realities of life imposing on social networks once people reach maturity.

I really enjoyed Mike Gualtieri’s post on Forrester’s blog: “Excuses, excuses: The Business Doesn’t Know What it Wants“.  The two big culprits:

• The business doesn’t know what it wants.
• The requirements keep changing.

But my favorite advice he gave to IT professionals immediately followed this:  “Get Over It”.

I couldn’t agree more.  Of course the business doesn’t know what it wants in BPM because they’re tackling a domain that is new to them (BPM), and they’re tackling a moving target (the Business Process).  And this isn’t unique to BPM, far from it.  And despite this, many projects are successful.  So obviously the fact that the business “doesn’t know what it wants” is not an excuse for failure.  If you’re collaborating with the business on a solution, help them figure it out by prototyping, iterating, and helping them understand implications they might not have though through.

The other bits of advice are equally good:

• Understand the Business and Your Users
• Build for Change
• Get Passionate about your Craft

Mr. Gualtieri notes that the “industrialization of software development has been an epic fail.” I agree.  From my point of view industrialization was always the wrong goal.  Software development is more a craft than an assembly line.  One learns the craft through many thousands of hours of practice and through mentorship from masters of the craft.  And despite the fact that the news media and other nontechnical people view software development as utterly lacking in creativity and design, they are mistaken.  Software development is an intensely creative effort, when done right.  Which explains why so many projects fail when they go for the lowest-cost-possible staffing models.  In fact, BP3 and other boutique firms like ours are often brought in to rescue projects that were, at first, given to the low-cost provider.

Ok, no more excuses, BPM practitioners.  Let’s get out there and deploy some processes.

One of the sessions at Forrester’s Business Technology Forum 2009 was a lunch session sponsored by Appian on the subject of Iterative or Agile development and BPM.

Sandy Kemsley quotes Tom Higgins of Territory Insurance Office in Australia as saying “Waterfall contracts and iterative development don’t mix.” Apparently he spent quite a bit of time talking about the contractual aspects of the project they took on with Appian, and Sandy took the opportunity to comment as follows:

The contract needs to focus on risk management, and you can’t let your lawyers force you into a fixed-price contract that has pre-defined waterfall-type milestones in it if you don’t know exactly what you want; in my experience, no BPM project has ever started with the business knowing exactly what they want ahead of time, and I don’t imagine that many do, so don’t mistake a contract for a project plan. If you plan on doing iterative or Agile development, where the requirements are defined gradually as you go along, then a fixed-price contract just won’t work, and will be a higher risk even though many (misinformed) executives believe that fixed price is always lower risk.

It is certainly true that waterfall contracts (often milestone or deliverable contracts are really waterfall contracts, so beware) are not an optimal fit for iterative development.

Having said that, you may find yourself in a situation not of your own making – where a Waterfall contract has been put into effect, and you have the responsibility of delivering the project.  At such times, it is still in your interest to convince the project team to go down an iterative path and get the contract revised to reflect it.

At BP3 we have been brought into just such situations when major outsourcing shops bring our firm in to help lead a customer BPM deployment.  We articulate the value to both parties to help them see the light that although the Waterfall contract would allow a lot of choke-the-vendor opportunities, and a lot of change-order opportunities – it would also bury the team in change-order requests, and it would likely fail to meet the business objectives and time-lines.  We do this by making a simple commitment to both parties:

1. The business will prioritize the work in each iteration (In other words, the business MUST prioritize).
2. The delivery team will deliver the highest priority work in a quality, repeatable fashion (in other words, technical team will honor the business’ prioritization decisions)
3. The iteration will be accepted if the business accepts it as having substantially delivered their top priorities and as having prepared the team for moving to the next iteration.

The difference in productivity, and in the tenor of the relationship is dramatic.  Of course we have to follow up words with deeds – delivering value, and delivering on the priorities the business has set for the team.  We have to take commitments seriously.  After establishing a pattern and habit of success with this new paradigm, we’re much more likely to achieve success.

A more common scenario is to get into a waterfall-methodology-oriented environment, where the contract may be more generally structured (perhaps even T&M).  In such cases, we have had a lot of success in applying iterative and/or agile techniques within the overall waterfall framework – including characterizing early development work as prototyping or design work, in order to pull some of the riskier technical or requirements issues to an earlier point in the deployment.

Regardless of the situation you find yourself in, you’re going to be better off if you can apply iterative techniques to your BPM deployments.  Once you apply those techniques, success will reinforce the approach.

Sandy makes another point in her post about working with people you trust – I couldn’t agree more.  If you don’t have that trust in your customer relationship, you have to work hard to earn it. If you don’t trust your vendor, find someone you do trust.

As a proposal, challenge yourself to think about your project as “Fixed Effort” rather than “Fixed Price” or “Time and Materials”.  What is Fixed Effort?

1. Honor the budget by deploying the process within the allotted budget.
2. Use iterations to always stay close to a production-worthy deployment.
3. Always work on the highest priority elements that meet the business objectives, and get you as fast as possible to a “minimally viable process” (For more information on this subject, look for Minimum Viable Product or MVP).

This approach honors the realities of the world that are often ignored at the peril of the project and its team members:

1. The Budget is LIMITED.  Fixed effort honors that by delivering a production ready process with real ROI within that budget.  Let’s say that again:  a Fixed Effort project honors the budget by delivering a production-ready process with real ROI within the budget.
   
2. Wrong requirements are among the most expensive mistakes a project can make, if they make it to production.  Iterations and Agile methods will expose these missed/mistaken/wrong requirements earlier in the process.
3. By always staying close to a production-ready release, at any time the Business should be able to say “this is good enough” (translation: we have a minimum valuable process), and you should be within just a couple weeks of going “Live” by doing a little cleanup and final QA before go-live.
4. By focusing on the business priorities, we’re focusing on the parts that add the most value / ROI – rather than the check-boxes that might meet IT requirements or might make us feel better about the project.
5. If pieces are left off in the end – they are likely less valuable and provide less return than the parts we’ve already implemented.

I realize “Fixed Effort” may not catch on in popular lexicon, but it keeps you focused on realistic budget in BPM projects.  The requirements aren’t fixed, as they are in a typical “Fixed Price” contract, so the vendor can’t easily commit to delivering static requirements.  A Fixed Effort approach is the way to address that requirements risk, while still addressing the budget risk.  Its a balanced approach, and managed properly, it works really well.

The BTF09 Event can be summarized in one word, literally:  LEAN.

I have to hand it to Forrester, someone decided Lean was the message of the day, and they have delivered that message consistently.  You can find the feed on Twitter here.  To  make it easier, use this link instead to see the lean references along with #BTF09.

A quick review of Sandy Kemsley’s write-ups of sessions yields the following topics that refer to Lean:

• Why Lean is the new business technology imperative
• Lean and the CIO
• The Power of Lean IT
• Embrace Lean thinking to enable innovation
• How can Lean Software Enable you to Better Serve the Business?
• Can packaged Applications ever be Lean?
• Forge your Lean process improvement gameplan
• Lean application development strategies.

There was even a UX design session where the presenter made the argument that UX design is “Lean”.

Someone should have tweeted that all this tweeting isn’t very “Lean”…   And I guess no one had the discussion about whether attending a conference is “Lean”… Which is precisely why we shouldn’t try to apply the word “Lean” as Good and “not-Lean” as Bad.  Not everything we do that has value is “Lean” – something I am acutely aware of having had to read “Pigeon Wants a Puppy” to my daughter twice the other night.  It wasn’t Lean, but it had a lot of value!

There is a sense from reading all the traffic on twitter and blog posts that Lean is good and Not-Lean is bad.  Honestly, I don’t care if “SalesForce” (insert favorite SaaS product) is Lean, but I do care if my “Sales Process” is Lean.  And even more than that, I care if it produces reliable revenue streams at reliable cost outlays.

I don’t care if a COTS (Commercial Off-The-Shelf) Software package is lean vs. custom-coding being lean – I want the solution that solves my business problem with minimal cost and maximum fit for purpose, and I care that the processes that require this software solution continue to operate “efficiently”.  More simply – whether my car was constructed in a Lean fashion or not, how I use a vehicle in my business may prove to be Lean (or not).  The car at the point that I care about it, is already a finished product and I take it or leave it largely as-is.

To the extent that the point of Lean is to eliminate waste, you can almost characterize anything that eliminates waste as Lean – but that misses the point of using Lean as a process improvement method.  And Let’s not forget that you’ll still need other tools in your utility belt – six sigma for identifying and eliminating defects and variance, software for maintaining a good solution over time, and leadership to get your project over the finish line in challenging times.

Taking a step back, we have to remember that Lean is a means to an end, not the End itself.

Well, this was a surprise for me this week – the news that Software AG (SAG) is buying IDS Scheer.  Clearly there are complementary businesses from the perspective of what they’re tackling (SAG being integration centric, IDS Scheer being very modeling and enterprise architecture focused).  Everyone seems to be waiting for the other shoe to drop – what will Oracle, SAP, and other players in the space do as a result of this acquisition?  Are more acquisitions to follow?

As Forrester points out, “IDS Scheer needed an execution engine in order to remain relevant and credible in the eyes of process pros responsible for expanding enterprise BPM initiatives.”  So it looks like a good fit from that perspective, and also from the point of view of altering SAG’s image as being too integration-centric (reinforced by acquiring Webmethods).  Forrester expects a successful marriage, with the “big losers” being the big partners of IDS Scheer: Oracle and SAP.

More coverage from “BPM in the Real World” on ebizQ here.  Based on a reading of posts on Twitter, there is some speculation that SAG now becomes a tasty target for SAP.  But then, SAP isn’t known for paying a big premium in its acquisitions…we’ll see.

Connie Moore’s (of Forrester) recent posting on collaboration and BPM got my attention primarily for the following quote:

But I’ve been a voice crying in the wilderness. I’m not kidding.  Whenever I would talk about collaboration with BPM vendors, they would somehow think I was talking about straight through processes between companies. That’s collaboration, right???  And whenever I would talk about BPM with content and collaboration vendors, they would look at me blankly and mumble something about using simple workflow for approving documents.  It felt like two disconnected worlds that desperately needed to find each other.

I can very well imagine this conversation with these vendor communities.  Connie sees reason for optimism, and I agree – but we still have a long way to go on this front.  Keep fighting the good fight!

Dennis Byron has a post up on the BPM in Action blog about technology for BPM in the Cloud, in which Dennis even drops the bomb that he is now convinced by his research (converted, as he put it) into the opinion that the cloud is not just SaaS redux.  There are a couple of good links off of this article for background reading as well…

There’s an even more amusing read from Forrester’s BPM Blog by Robert Richardson.  He notes just how many cloud announcements (or SaaS announcements – unlike Dennis, he doesn’t clearly delineate which is which in his post).  The announcements are proof that not only is BPM a robust market, but that there will be no shortage of either new entrants, rebranded entrants, or simply companies that hadn’t hit my radar before.  He points out that Singularity, Cordys, IBM, Vitria, Appian, and Software AG have all put out SaaS or Cloud announcements for their BPM software.  If you add in Lomardi’s recent announcement of the Spring 2009 Blueprint Release, you’ve got yet another announcement, all in roughly 2 months.

I have to admit that for me, some of these companies have a lot to prove before I believe the press releases (I need to see it to believe it) because of past history of either management or the company.  Some companies have a history of promising without delivering in this space.  Appian and Lombardi have both BPM credibility and good SaaS credibility due to their respective offerings (Vitria, for example, is clearly more known for integration, and so is Software AG, and for that matter IBM).  Alignspace is still in beta (I’ve applied but you can’t just “get in”), but is the most “BPM-like” thing I’ve seen from Software AG yet.

I think its a good play for most of these firms, at least from a marketing point of view (not knowing how much their investing I can’t evaluate whether it is a good R&D investment): firstly, they potentially get to change the conversation to one centered on the SaaS-ness of the offering, rather than the BPM-ness of the offering; and secondly, they get a round of press about the SaaS or Cloud aspects of what they’re doing rather than just the BPM buzzword which is, no doubt, a little harder to excite journalists and bloggers with!

Looks like I wasn’t the only one who noticed that IBM picked a name for their new “social BPM” site that sounds suspiciously like the most familiar name in that space – Lombardi’s Blueprint.  In my previous post, I noted that the naming seemed a bit suspicious (IBM’s BPM Blueworks) in that there’s no particular reason to include the word “Blue” in the name…

Meanwhile, Jim Rudden, VP of Marketing at Lombardi, responded on their blog:

In particular, we could not help but notice the name similarity with Blueprint — our cloud based process mapping and modeling application that has been on the market for two years. Now, before you call me paranoid, know that we average several thousand hits to our website per quarter from IBM labs in China, Italy, Germany, Canada and the US. And we get dozens of requests for Blueprint accounts from IBM Labs across the world every quarter. So, at the very least, the IBM team was aware of Blueprint — if not imitating it. They are not the first to follow Blueprint’s lead — and won’t be the last.

Jim doesn’t pull too many punches in his response to IBM’s announcement.  It is certainly interesting that IBM labs are hitting Lombardi’s Blueprint so frequently, and requesting so many accounts. He has some substantive arguments about whether IBM’s release will really “democratize” process modeling the way Lombardi’s Blueprint purports to do (its a good read whether you agree or not).

Meanwhile, Forrester’s business process blog has made note of the IBM announcement as well, in a post titled “Not Your Daddy’s IBM” by Robert Richardson. He accurately describes IBM’s participation in the BPM market circa 2006, and concludes from the announcements at their annual user conference that IBM now “gets it”.  I think it is reasonable to assume that IBM picked up some new BPM-related “DNA” with some of its acquisitions – notably that of Webify here in Austin, TX.  But IBM is a big company, and change comes slowly.  Although I think BPM makes even more sense for IBM to focus on than SOA, they have, instead, been beating the SOA drum for the last 5+ years.  So I think we’re justified in taking a wait-and-see attitude about announcements, and wait to see the shipping products.

IBM is due to release BPM Blueworks on June 26.  Lombardi is about to deliver a new version of Blueprint as well (they ship new versions approximately every quarter, and Blueprint has been live for over two years now).  Hopefully IBM will offer trial versions so we can do a bit of a comparison at that point (and maybe a few more fireworks).

I don’t have a lot to add to Forrester’s review of Blueprint, but I thought it would be worth linking to here.  First, Lombardi’s blog includes a reference to it, and if you want to get directly to the article just click here.

We’ve had several previous posts about blueprint and its reviews, which you can find right here.