I have been working in the Identity and Access Management (IAM) area
over the last few years. Working with the development team and by
talking to customers and customer facing experts I have understood the
journey of the code from a development environment to a powerful server.
But the journey doesn't end there. The moment software gets deployed
the product requirements change. The customers want tweaks to the
product or want new features and suddenly we realize what we built needs
to be rebuilt. Sometimes the customer doesn't want our advanced
features. Some customers don't want anything new. Some customers want
better support instead of new features. In this blog I have tried to
capture some of my experiences and learning dealing with enterprise
customer.
Adoption
Product adoption at the customer site is an important part of the
product lifecycle. Enterprise customers buy a lot of products which are
never deployed. There are many reasons why a product is not adopted. It
is the development and product management mindset that are primarily
responsible for this problem.
One major flaw is the wrong notion of supporting new features. In the
IAM world it can be translated to supporting newer protocols. New IAM
protocols are proposed almost every month. OAuth, OpenID, OpenID
Connect, SCIM, JWT, SimpleAuth ,etc sprung up within the same period.
Development teams spend months building these protocols only to realize
that the customers have no plans to move to these new protocols and
instead want to use the old mature protocols. Cost of re-deploying, the
lack of trust in the new protocol and integration with other systems
that do not adopt new protocols are some reasons behind the lack of
adoption. The development organizations need to understand the use cases
that will drive a need for newer protocols at the customer site with
good migration and integration stories for the customer.
The other flaw is "Internet Trends". Just because the internet facing
B2C firms use the protocols does not indicate a change in trend. B2C
firms evolve themselves into using these protocols out of a business or
technical need whereas enterprise customers are resistant to change.
Strong statements and finger pointing by industry experts won't
necessarily drive a change in the enterprise customer's psyche. If the
enterprise customer is actively involved in the protocol standards
groups or communities that drive these protocols then the chances of
adoption are higher. The development teams need to work closely with the
IAM architects in the customer site and understand the needs before
starting work on these new protocols.
Customers in certain parts of the world are more willing to accept
changes. Automobile firms such as Ford has an office in Silicon valley
and is experimenting with APIs in the vehicle. 3rd party applications
are being built to consume and produce data pertaining to a
vehicle.Whereas there are customers in other parts of the world who
still use legacy systems and do not plan to migrate to newer software
stacks. The product management needs to understand the intricacies of
geography location and work accordingly. Most of the time the product
management sits in a mature and adoption friendly geography and dictates
the terms. This net result is a skewed view of the world outside and
thus poorer adoption.
With the expansion of cloud deployments almost every enterprise has been
sold or in the process of being sold a cloud based solution. Apart from
the usual problems of confusing license costs for cloud deployments
even though the sellers may think otherwise, security concerns and
ownership worries the biggest challenge is migration and integration.
Most of the B2C cloud deployments involve smaller applications but a
large enterprise has legacy applications that need custom integration.
All this make the case for cloud solution weaker. However, according to
my experience, newer deployments that do not integrate with legacy
applications is a good starting point for cloud deployments and there
are positive signs there.
Building the product
I come from a development background with passion for intricate
details. My eclipse environment and Firefox browser are stuffed with
developer tools. But, over time, I realized that the passion for
building a product is a useful trait but even more important is to see
where and how the product fits in the market. Again there are some
problems running deep inside the development organizations.
"Standards" myth. Development builds products which might follow exact
specifications of an IETF document. It is an overkill most of the times.
Customers do not want the exact standards but want flexible
architecture that allows them to plugin and play their code. In the IAM
space a classic example is that of OAuth. The confusion should to be
solved by providing customers a way to use what they need.
"Beta" feedback. Almost every customer who is involved in the beta
actually doesn't use the product to its fullest. It is even more
trickier in case of IAM products. They are generally large scale and to
test and deploy it for a beta is time consuming and costly. Ideally,
beta environments need to be hosted by development teams. They need to
simulate customer environments and allow customers to use the
environment. This happens rarely as the development team is running
behind schedule most of the times.
"Agile". Most of the development teams have a "Fragile Agile" model.
They just break the huge waterfall model into smaller chunks and call
it Agile. Production code is released once every few sprints instead of
every sprint. The development teams slip stories and the sprints more or
less become a formality. Test driven development is almost non
existent and the hotchpotch way of building products the "Fragile" way
ruins the quality. My blog on Agile failures (coming soon) will give a
deeper explanation of the mess. In case of IAM products this spells
doom. Invariably, the test team is behind schedule and is forced to
finish their work quickly resulting in security vulnerabilities,
performance problems and bugs. When these problems are exposed it shows
the development team in bad light and affects the brand name.
Development teams need to take a stance and figure out whether they
really are Agile and does it even make sense to be Agile.
Competition
Nothing drives an organization more than the competition. It is both
good and bad. But I feel there is a defensive technique used by the
sales team that doesn't help the customer. We are told that no salesman
gets into a feature war. Yet they put number of slides in the
presentation that contradicts the previous statement. Feature wars exist
and cannot be ignored. But, most of the times the features developed
out of the fear of completion ends up being a bad copy of the original
creators. If the market for that feature is already mature then the
development teams just waste their time building it. In the IAM space it
results in the development of features that may never be used. Such
features help the sales team but not the customer. IAM products should
have a niche and brand. The brand should be strong enough for a win. The
product management
needs to figure out if they want to be jack of all trades and master of
none or jack of some trades and master of one.
Another classic selling strategy is the end to end selling. The
presentation slides and technical demonstrations show all the happy
paths of integrating the entire software stack. Almost every competitor
boasts of the exact same end to end solutions. The product management
needs to decide if it makes sense to integrate so many products just for
the sake of competition. IAM products should have logical integrations
that should not be driven out of competition but out of actual needs.
Price is another area driven by competition. Large enterprises fund
development shops on an hourly basis. At the end of the year when
development costs are compared with the sales revenue there is a gap. It
is primarily because the products built were priced according to
competition instead of its actual value. The sales team gives discount
and thus put pressure on the development team to further reduce cost.
The end result is less developers or substandard developers who can only
take a product to its doom. IAM pricing is critical for the
organization which sells the product as well as the customer who gets
value from it and should not be driven by competition.
Summary
My views may sound idealistic but I can confidently say that in the IAM
space there are players who have or are building a niche for themselves
and building really fast. The key idea is to understand customers, know
your development team well and not get too bogged down by competition.
This will result in better and safer software.
No comments:
Post a Comment