Would you trust a car salesman who’s not driving the type of car he’s trying to sell you? Would you trust a nutritionist or a dietitian who’s not in a good shape? Probably not. There are two things that I suggest we all ask of BI vendors. Ask if they:
Use their own BI tools to run their company. Next time you interview a BI vendor, ask for a proof that their own CxOs and all other strategic and tactical decision-makers are using their own tools. I know of some cases where they don’t. How can a vendor convince you to buy its solutions if it hasn’t convinced its own people?
Adhere to the same best practices they suggest you implement using their tools/solutions. Transparency is one of them. One of the top use cases for enterprise BI is transparency: full visibility into companies processes, people, policies, rules, and transactions.
Today’s contact center ecosystem is complex, and comprised of multiple vendors who provide the critical software components. Read my blog post on what these critical software components are. Customers are looking for a simpler technology ecosystem to manage from both a systems perspective and a contractual perspective.
Suite solutions, available from unified communications (UC), CRM, and workforce optimization (WFO) vendors, are evolving and include comprehensive feature sets. These vendors have either built these capabilities out or acquired them via M&A activity. And we expect more M&A to happen.
Are you winning? No, this is not about Charlie Sheen! I mean, are you one of the “fortunate” ones leading application delivery in a firm that is winning?
Today’s economy is a mix of winners and losers, with winners weighted strongly toward firms, industries, and regions experiencing rapid growth in customer demand for experiences that integrate their lives across multiple digital (mobile, web, …) and physical (retail, auto, …) touchpoints. App delivery leaders experiencing this rapid growth would say it is “the best of times,” except for how hard it is to keep up — the business demands more and more, faster and faster! So “winning” can be a mixed blessing in software, too:
Relevant Advice For “Winning” App Delivery Leaders
Now that Agile has moved into the mainstream, it is encountering a whole new raft of challenges, including compliance. The word on the street for at least the past couple of years is that trying to be Agile and satisfy regulatory requirements is a lot like juggling chainsaws and machetes: theoretically possible but certainly not advised.
Fortunately, the word on the street is nearly always wrong. When I started interviewing people who had made Agile succeed in highly regulated environments, I expected to hear a lot of handy best practices that I could synthesize into a research document — essentially, a tactical guide to compliance. If you're a medical device company and you need to document six ways from Sunday how you validated and verified the software embedded in a new device, here's what you might do. If you need to deal with the auditors, here's where an investment in an application life-cycle management (ALM) tool might help.
Although this type of research depends on interviews, it's worth taking a peek at the available survey data to see if it has any additional insights. And boy howdy, am I glad I did. Sifting through the data collected in the survey that Forrester did in conjunction with Dr. Dobb's Journal, I found the first of two big surprises about Agile and compliance:
Agile adoption in the most regulated industries is not significantly different from the adoption rate everywhere else.
Our latest BI solution center (BISC, which in our definition is more than a BICC/BI COE) report is now live on the Forrester website. Here’s a brief summary.
Forrester firmly believes that tried and true best practices for enterprise software development and support just don’t work for business intelligence (BI). Earlier-generation BI support centers — organized along the same lines as support centers for all other enterprise software — fall short when it comes to taking BI’s peculiarities into account. These unique BI requirements include less reliance on the traditional software development life cycle (SDLC) and project planning and more emphasis on reacting to the constant change of business requirements. Forrester recommends structuring your BISC along somewhat different lines than traditional technical support organizations.
Earlier-generation BI support organizations are less than effective because they often
Put IT in charge
Continue to be mostly project-based
Focus too much on functional reporting capabilities but ignore the data
Customers expect the same experience every time they interact with a company — whether it be when researching a product, completing a sales transaction, or getting customer service — over all the communication channels that a company offers. They also expect companies to have an understanding of their past purchase history and prior interactions. Finally, customers further expect that each interaction with a company adds value to their prior interactions so that, for example, they do not have to repeat themselves to a customer service agent when being transferred or when migrating from one communication channel to another during a multistep interaction.
How many companies can deliver a consistent service experience in this scenario?
Three fundamental elements are needed to deliver a consistent customer experience across all communication channels:
A unified communications model. Companies need to queue, route, and work on every interaction over all communication channels in the same manner, following the company business processes that uphold its brand.
A unified view of the customer. Each agent needs to have a full view of all interactions that a customer has had over all supported communication channels so that the agent can build on the information and experience that has already been communicated to the customer.
Unified knowledge and data. Agents need to have access to the same knowledge and the same data across all communication channels so that they can communicate the same story to their customers.
It feels as though the word "value" has appeared in more discussions about software development and delivery than in the previous two decades. We see this increased demand for immediate, tangible value across the entire range of technology producers and consumers. The dubious value of legacy applications, which have grown like kudzu, is the impetus for many painfully difficult cutting and pruning jobs within IT departments. Faster realization of value is driving more applications and infrastructure into the cloud. Software vendors are realizing that, while revenue is vital, the long-term relationship with the customer depends on the mutual value that both parties think they're getting from the relationship.
If we measure software by value, instead of cost, revenue, completeness, or other possible measures, we have to measure the software development process in a complementary way. What characteristic of software development is most likely to generate a valuable result? If your answer is "speed," think again. Predictability is a much better measure.
At the IBM Innovate conference last month, Walker Royce made a very plausible case for valuing predictability over velocity. Here's his keynote address, which is definitely worth watching.
I don’t understand why firms spend millions of dollars on Java application servers like Oracle Weblogic or IBM WebSphere Application Server. I get why firms spend money on Red Hat JBoss -- they want to spend less on application servers. But, why spend anything at all? Apache Tomcat will satisfy the deployment requirements of most Java web applications.
Your Java Web Applications Need A Safe, Fast Place To Run
Most Java applications don’t need a fancy container that has umpteen features. Do you want to pay for a car that has windshield wipers on the headlights? (I wish I could afford it.) Most Java applications do not need these luxuriant features or can be designed not to need them. Many firms do, in fact, deploy enterprise-class Java web applications on Apache Tomcat. It works. It is cheap. It can save tons of dough.
Expensive Java Application Servers Sometimes Add Value
There is a need for luxury. But, you probably don’t need it to provide reliable, performant, and scalable Java web applications. Application server vendors will argue that:
You need an application container that supports EJBs. EJB3 fixed the original EJB debacle, but why bother? Use Spring, and you don’t need an EJB-compliant container. Many applications don’t even need Spring. EJBs are not needed to create scalable or reliable applications.
Business rules platforms are a mature technology for automating decision and policy logic and for managing fast changes to that logic to keep up with business changes. Now customers are seeking more: capabilities allowing them to employ business rules to help detect and respond to business events hiding in streams of data and to automate decision life cycles. This research reveals how well vendors are responding to these new requirements.
Application development and delivery (AD&D) pros are taking business rules platforms in two new directions. The technology's future will be determined in large part by whether or not customers can successfully apply it to business event processing and decision life-cycle management.
Business event processing applications answer the question "What activities are happening in the business now that I need to know about?" by searching for patterns and values within several streams of actively flowing data. The streams almost always represent information about the real world, such as customer activity in a casino, stock prices fluctuating in real time, or the location of transportation vehicles and the goods they carry. AD&D professionals often build business-events applications using complex event processing (CEP) platforms — some of which use rules to define event patterns. Other AD&D professionals use business rules platforms to build business-events applications. These overlapping uses set the stage for the convergence of CEP and business rules platforms.