Featured

The Art of Under Promising and Over Delivering

According to the McKinsey/Oxford study half of IT projects with budgets of over $15 million dollars run 45% over budget, are 7% behind schedule and deliver 56% less functionality than predicted (Bloch, Blumberg, and Laartz, 2012).

Providing value as a consultant to a client without compromising the bottom line of either the consulting company or the client is an art. Consultants deserve compensation commensurate with their level of intellectual capital gained through knowledge and expertise. Clients deserve to receive services that solve the problems consultants are engaged to disentangle. To build a strong foundation that creates a successful client-consultant relationship requires honest communication on both sides during the elicitation and analysis of requirements phase.

During the relationship-building negotiation phase, a client wants the lowest price for the least amount of hours to complete a project. The consulting company must understand what the client wants to achieve and determine if client expectations can be met within the budget and hours the client has in mind. Consultants must deliver on time, add value, and make a profit. Overcoming the challenge of immediate cost savings on the client side and the true costs for a project on the consultant company’s side is a delicate balance. A balance that if lopsided will negatively affect the success of project goals. If a consulting company accepts terms they know are unrealistic, client expectations are not met. Under promising and over delivering takes practice, wisdom, and time to perfect.

Experience is one of the keys to achieving this balance. Wise consultants understand the power of managing a client’s expectations. Professional consultants do not over promise, or suggest a client lower expectations and submit a plan that really does not provide the ideal solution. Honest communication with a client is based on showing how the consulting company’s plan will drive value, even if the price point is above the client’s initial budget consideration. Deliverables that make the client happy set a precedence for solidifying additional work, and creating a long-term, win-win relationship.

Frequently, consultants have a solution in mind before approaching or establishing a relationship. Projects are less likely to succeed when preconceptions get in the way rather than providing advice based on client needs. The preconceived notion approach is the default position for the super-salesperson who is less worried about building a long-term relationship with a client, and more concerned with short-term, new business transactions accomplished by recommending solutions du jour.

Ultimately, the key ingredient to keeping clients happy is active listening. Effective listening is a skill. Some people are skilled listeners. Many are not. Effective listening allows a consultant to accurately, communicate client project expectations and anticipate client needs.

Remember, don’t take on more than you are prepared to be held accountable for. Provide evidence-based estimates with confidence. Resist the temptation to guesstimate about what your client truly needs, and prevent your projects from becoming IT failure statistics.

Bloch, Blumberg, and Laartz. (2012). Delivering large-scale IT projects on time, on budget, and on value. McKinsey&Company. Retrieved from http://www.mckinsey.com/insights/business_technology/delivering_large-scale_it_projects_on_time_on_budget_and_on_value

REST Governance Key Signature

The REST Governance Key Signature

 

Much of the hype around service governance is focused on operational governance. Defining, tracking, and managing factors like service-level agreements (e.g., average response time, peak response time, average throughput, peak throughput) and authorization policies (e.g., users from organization A are allowed to invoke this service while users from organization B are not) are very important.  Once service components are up and running within an organization’s IT infrastructure governance is necessary.

Operational governance and management are necessary but insufficient for successful service deployment. To effectively define and implement a REST service, and not simply implement a series of point-to-point REST services masquerading as REST, which create another layer of technology spaghetti, REST services must extend governance back to development and architectural REST perspectives. Find a way to seamlessly bind REST perspectives to enable effective information flow in multiple directions⎯from architecture to development to operations.

Taliferro thoroughly investigated each governance perspective.

Architectural Governance

Architectural governance at the enterprise architecture (EA) level involves three key elements:

  1. core decisions about business or technological functionality within the enterprise
  2. documenting decisions so that downstream consumers (the teams responsible for developing and deploying services and    applications) can quickly understand and make effective use of those decisions
  3. reviewing project-specific application of decisions

In order for an EA team to execute tasks, the team must have an effective way to disseminate produced knowledge assets. In addition, the team must track and understand which knowledge assets are applied to specific projects. Further, an EA Team needs to document the review of project-specific decisions.

Design-Time Governance

In many ways, Software Development Life Cycle (SDLC) governance within a REST initiative is a reflection of decisions made at the enterprise architecture (EA) level. Decisions about the scope and granularity of implemented business services and technical approach used in implementing the services must be applied to specific service production or consumption (i.e., application development) projects.

However, SDLC governance extends beyond appropriate application of EA guidance to the analysis, design, implementation, and testing of the resulting services and/or applications required by the IT project. Regarding service production, SDLC governance involves the progressive “hardening” of a service. Services progress through requirements definition, design, implementation/unit test, and integration/system test phases to eventual deployment in the operational environment, oversight is needed.

When applied to service consumption, governance may involve both internal project-specific reviews (e.g., appropriate services selected, requirements for new services identified). External reviews from the perspective of service providers allow for such questions as:

Does the use of this service within this application conform to enterprise-specific or government-mandated privacy rules?

Does the service implementation contain open source components?  If so, do the components compromise enterprise-specific intellectual property?

Operational Governance

Operational governance/management within REST involves applying appropriate business and technical policies (e.g., groups and users allowed to invoke a particular service, minimum throughput and response time expectations required of a service) to deployed services. Business policies are often implemented within REST by a Service Bus or some fabric integrated with the enterprise’s authentication and authorization infrastructure, while technical policies are typically monitored by a services management platform. The cumulative set of governed technical policies is often referred to as a service-level agreement (SLA).

Examples of SLA-level technical governance elements within REST:

  • Average throughput
  • Peak throughput
  • Type and description of committed SLA
  • Availability
  • Consuming service clients
  • Hardware and software configuration
  • Fault history
  • Alert thresholds

Political Aspects of REST Governance

How do we map  governance disciplines into an organization’s structure and roles? The nature of REST governance creates a new discipline with implications for existing corporate and IT institutions. The implications affect new organizational structures and processes and the politics associated with those structures and processes.

To make governance a valuable and necessary function that supports REST migration one needs to understand

  • corporate service policies
  • what governance means
  • how governance helps achieve successful implementation
  • the impact on current IT governance processes.

Some processes include budgeting and project approval, portfolio management activities, and ongoing oversight of projects to assure budgetary compliance. Applying governance to REST activities is critical because changes to normal IT governance processes for budgeting and portfolio management may be necessary.

Think about the budgeting process of an organization. The budgeting process has tremendous impact on organizational behavior in general, and IT departments in particular. Without budgetary project control to influence REST adoption and reusable services as fundamental design concepts, projects are only driven by requirements of a specific business unit, or project. The same logic applies to portfolio management.  Governance, budgeting, and portfolio management are methods used to influence business unit behavior, and IT departments to aggressively support REST and reuse. Enterprise architecture processes undergo changes as a result of an organization’s REST initiative. Often the architecture process and organization have to be restructured to accommodate REST requirements because the skills, roles, and functions of an EA team are not appropriate for a REST initiative.

Examine the process of architecture as tiers of activities: one tier involves architecture strategy and goals, definition of elements, standards, and the other architectural goals. The latter tier involves funded projects either through architecture, acquisition or implementation. Even though management may want both tiers to interdependently function, the two tiers are related, yet distinct processes. For example, at corporate headquarters a chief architect or central architecture group along with solution architects are assigned to projects. They build systems and implement technologies and standards. Usually, the business unit that funds a project has the most influence. The behavior associated with enterprise architecture is similarly related to the organization and processes used to achieve the goals of REST:

  • architecture compliance
  • portfolio management
  • budgetary compliance.

 

Summary

Don’t think managing your REST implementation operationally is enough. Keeping tabs on execution does not ensure the service is really supporting overall business goals. Traceability to business goals/priorities through EA to SDLC to operations make REST implementation successful in the enterprise. Equally important, do not minimize organizational influences that are needed – monolithic, project-centric funding models are not likely to work in the world of REST.

http://wp.me/p2MYVz-P

Booker Showers

What I would like to see in a Sales Force Automation Tool

What I would like to see in a Sales Force Automation Tool

 

Accountability

Accountability begins with an open environment. Open environments help motivate. When everyone on the sales team can see the contributions of each other, the natural result is more productivity. On the other hand, a lack of information allows less motivated people to remain hidden.

Sales Management

Sales Management should provide managers and representatives with the capability to easily log and track leads, opportunities, and sales orders. In addition, capability should permit managers to run opportunity and revenue forecasts using criteria such as step, status, source, demographic, sales reprentative, and company.

Moreover, allow sales personnel to build complex profiles and assign diverse criteria to each contact and/or company. I would like to forecast project commissions with varying degrees of granularity.

Tie e-mail, reminders, and opportunities together as one unit.

Wouldn’t it be effective if Sales Management captured sales leads and put a follow-up system in place? Such functionality is essential to generating consistent revenue growth. Most sales people are very busy managing relationships and potential sales, which can lead to some prospects falling through the cracks. What if there was a proactive e-mail reminder system used in conjunction with sales management to keep sales people on track?

In the mobile world, having access to possible leads is part of the picture. Seeing every lead with the probability of closing the sale is something entirely different. Without the context of probability, real-time sales forecasts can be difficult. Give sales managers the ability to confidently make forecasts on-the-fly, at a moment’s notice.

Sales Management, Teamwork and Collaboration

A lack of individual accountability often stems from poor systems allowing people to hide poor performance. An open environment, where everyone can see what everyone else is doing, goes a long way to promote a sense of teamwork, while uncovering productivity problems. Optimal systems ensure strong performance is rewarded, and uncovers poor performance.

The accessibility of mobile-based, detailed notes related to phone calls or meetings will also increase effectiveness. All the voice recognition software available makes this functionality doable.

Files

Associated documents should automatically appear given the amount of data mining tools available.

Understanding sales processes should be self-guided by the software; forecasts and funnels are intrinsic to a successful sales and marketing strategy. Software should be able to offer complete collaboration between sales representatives, managers and partners.

Is every functionality I have described too much to ask of an integrated Sales Management tool? Why do I need to open up various apps and modules to get a complete picture of the sales pipeline?

Certainly, in the post-PC age we can do better than the tools we have now.

http://wp.me/p2MYVz-un

Booker Showers

Tune Your Information

Tune Your Information For An Effective Mobile Strategy

 

An unfortunate fact⎯employees spend large amounts of time re-creating information. Organizations and customers need to make informed decisions. A maze of systems, sources, sites, and repositories where the right information to support decision-making may be stored present unending challenges. Systems either contain incomplete information or too much information users are unable to filter to support informed decisions. Often users do not know the information they are looking for is there…

For instance, most enterprise systems offer an application interface to expose capabilities online. True to the Pareto principle, 80 percent of users typically require only 20 percent of the system’s available capabilities. A mobile strategy must include users’ information needs, their privileges to use enterprise information, and their current objectives. Then, the mobile strategy through data mining dynamically assembles and delivers the right information to support objectives.

Therefore, personalization allows systems and services (adaptive agents) to understand the profile of each user, every electronic asset, and create a match with the right information.

Adaptability on an enterprise scale

Many enterprise software applications offer attractive solutions to discrete business problems but cannot scale to support cross-departmental or global challenges.

Trying to extend solutions in the enterprise often creates a cycle  of hardware upgrades and custom development, which is the IT equivalent of painting yourself into a corner – at a certain point, any way out is going to be messy.

In addition, today’s IT teams struggle with the pace of changing technologies combined with the needs and demands of business.
Every department, every team, and every line of business has a list of priorities for IT support. Every business development, every optimization of a process, and every innovation means one more request for a new application, feature or report.

Moreover, IT teams struggle to make maximum reuse of completed work. To reuse completed work may mean reconfiguring applications for redeployment, or buying off-the-shelf software to meet needs. Further challenges involve  maintaining completed work, which often runs on different platforms in different languages. Information management within a mobile strategy regardless of the volume of transactions, and content, across the breadth of an enterprise should work together.  Architecting to scale, allows the use of services as much as needed.

IT systems are never static and information is constantly in flux. A business can gain competitive advantage as a result of IT innovation. Essentially, an effective mobile strategy connects  information repositories with  users on demand while providing a consistent user experience.

http://wp.me/p2MYVz-ep

Booker Showers

REST Certification

The Need For REST Certification

The other day I heard Morgan Freeman and some acting colleagues read the United States Declaration of Independence aloud. Each word in the Declaration was carefully selected for meaning, brevity, and exactness. Is it possible to have such clarity in technology?

REST is the wild, wild west of architecture. People in the industry create a URL pointer to a SOAP backend and call the URL pointer a REST API.

Similar to how SSLs are issued through organizations such as Verisign and Thawte, there should be an authority that issues certifications for REST URIs.

Generally, I find the use of the acronym REST next to the acronym API a mistake. REST and API. Think about these two acronyms next to each other. Really, give the juxtaposition some thought.

Pause.

If your brain doesn’t explode from trying to reconcile the two acronyms then let me try to help you, so your brain does explode.

Often REST is used as an adjective to describe an API, which is not correct. Using the concept REST API literally means an architectural style that transfers a web resource’s state application programming interface, how can the meaning make sense?

Boom!! That should be your head exploding.

Pointing a URL to SOAP, a server class or method does not automatically create a REST resource. REST is a stateless, exploitation of Internet language and protocol for accessing characteristics or attribute/s (data) using the predefined HTTP action words GET, PUT, POST, and DELETE.

Many APIs defile the stateless constraint, which I could list as a separate article.

Consequently, there is no better time for someone to create a REST certification process than now. A certification process would ensure the resource is adhering to all the proper REST constraints, and ensure the resource is safe for use.

Booker Showers

What Happened to Good Ol' Competition - Is Innovation Dead?

What Happened to Good Ol’ Competition – Is Innovation Dead?

 

Back in the day, not too long ago, there were many companies competing in a specific marketplace for customers, not consumers. The customer was always right. Companies valued customers. Competition made services and products attractive to customers, and they flocked to the companies that not only provided the best products, but also the best customer service.

Today, customer service is a distant memory in many cases. A customer is no longer treated as valuable, but instead has transitioned into a consumer. Consumers have been deemed a company right. In multiple ways, innovation has taken a back seat. There is a pervasive herd mentality. Instead of different thinking and innovation, too many companies follow the crowd and conform. If companies don’t conform for whatever reason, litigation becomes a significant obstacle for nonconformists.

Companies become more powerful through acquisition by creating industry specific oligopolies, or a monopoly as opposed to the good old days of competition (Circa the advent of the Internet). Increasingly, today’s competition is wrapped up in patent trolls, and licensing litigation. Competition seems to exist only in sports and politics (if we believe what we see is true). The business world has seceded from the world of competition.

This article is not intended to point a finger at any one company, but to highlight a development in the business world that crosses industries, and detracts from innovation and unadulterated competition.

We need to consider how best our global future can be served by restricting new ideas and experimentation from those of us who have much to contribute. Should monopolistic behavior and litigation serve as the backbone of the business world in the 21st century, I think not.

http://wp.me/p2MYVz-sI

Booker Showers

Time Management

The Corporate Sonata – Time Management Strategy

 

(A Time Management Strategy)

Without a Grasp of Fundamental Principles that Drive Companies You Burn Money

When employees are organized and in control of each detail, a business operates like a classic sonata. Companies need business management systems that link to employee time management and personal information tools.

Time Management Strategy with a Groove

Time management systems should automatically integrate with each employee’s personal device. For example, when a manager delegates a task to an employee, does the task show up on his or her computer, tablet, and smartphone? Or, when management launches a project, does each team members’ tasks display and automatically update project details? If not, your company is only faking a time management strategy.

The Activity Waltz

Creating a corporate sonata means each employee through his or her time management system gains access to real time information to help effectively perform tasks. Tasks or activities are the backbone of our time management strategy. To focus on activities is important because instead of assigning activities to a project, our strategy is to flip this concept and start at the granular activity level. By first focusing on the activity we eliminate the disconnect between calendar programs, project management programs, and billing programs.

Tune Data Mining

Often ignored is how current activities affect future endeavors. We show you how to effectively use data mining to avoid the pitfalls that make a company less nimble and adaptive. Our strategic perspective prevents companies from developing paralysis at time when constant movement is crucial.

http://wp.me/p2MYVz-J

Booker Showers

Out of Tune with Anti-Patterns?

Not knowing how to spot an anti-pattern is just as important as spotting a defined pattern.

An Anti-Pattern is a pattern that reveals a problem implemented with a bad solution.

Identifying bad practices can be as valuable as identifying good practices.

A good Anti-Pattern also tells you why the bad solution looks attractive (e.g. it actually works in some narrow context), why it turns out to be bad, and what positive patterns are applicable in its stead.

An anti-pattern is something that looks like a good idea, but backfires badly when applied.

It’s not fun documenting the things that most people agree won’t work, but it’s necessary because many people may not recognize the Anti-Pattern.

In the old days, we used to just call these ‘bad ideas’. The new name is much more diplomatic.

While it is reasonable to assume that the principal reason people write software is to provide solutions to specific problems, it is also arguable that these solutions frequently leave us worse off than before we started. In fact, academic researchers and practitioners have developed thousands of innovative approaches to building software: from exciting new technologies to progressive processes, but with all these great ideas, the likelihood of success for practicing managers and developers is grim.

Booker Showers

Better Orchestration Through Folder Structure

Better Orchestration Through Folder Structure

Organizing resources into an appropriate structure is a major struggle for most implementors.  Unorganized resources makes it difficult to scale.  In addition, confusing folder usage as taxonomy instead of data usage places an unnecessary burden on a consumer of a resource.  Maximum orchestration can only be achieved through proper semantics.

A folder should contains all the resources that belong to the current data structure. The folder includes all files, resources and/or business data necessary to process a request.

Most of the time, there is only one data resource. Sometimes, there may be more than one data resource for the same composite resource (e.g., one for http and another on https).

A project folder should contain resources attached to a project. The composite resource may be divided into corresponding systems and inserted into a specific folder called by an orchestrator.

The specific folder name under the system folder contains all resources belonging to the current implementation. The specific folder includes all files and resources. For example, the folder will contain the XSLT files, the XSD files, WADL, and/or WSDL files used to call a resource.

An Infrastructure folder should contain all resources that are not specific to a particular project or implementation. The Infrastructure folder includes the XSD files, Query files, shared function files, and the WSDL file used to implement a generic service.

http://wp.me/p2MYVz-k

Booker Showers

29 Tips: Build Appealing REST Resources for Fun and Profit

 

A clear design philosophy can make REST implementation Fun and Profitable. Unfortunately, a company attempting to implement REST without guidelines will waste vast sums of money.

Thinking about implementing REST services? The following tips will help you plan a successful REST implementation:

  1. Consider REST if data returned is not dynamically generated and can be cached
  2. Use REST when bandwidth is particularly important and limited
  3. Use REST for lightweight resource elements within an organization only for integration purposes.
  4. Consider REST for web delivery or aggregation into existing websites because services can be exposed with XML and JSON. HTML pages can consume these resources without significantly refactoring an existing website architecture.
  5. Consider REST when exposing components across a firewall and to control clients who access the resource.
  6. Consider REST when supporting AJAX based clients.
  7. A REST resource should be completely stateless.
  8. A concrete implementation of a REST resource MUST follow four basic design principles:
    • Use HTTP methods explicitly
    • Be stateless
    • Expose directory structure-like URIs
    • Transfer XML, JavaScript Object Notation (JSON), or both.
  9. When creating a resource in a REST network (i.e., the Web) conceptualize and identify entities that need to be exposed as resources.  Look at the entire system and see what nouns (data) can be identified.
  10. Create a URI to each resource and ensure the resource is a noun, not a verb.
  11. Categorize resources in REST according to if a client can receive a representation of the resource, or if a client can modify (add to) the resource.
  12. Response formats should be specified using a schema.
  13. REST URIs should be nouns and easy to recognize.
  14. Hide server-side scripting technology file extensions (.jsp, .php, .asp), to allow porting to something else without changing the URIs.
  15. Keep everything lowercase.
  16. Substitute spaces with hyphens or underscores (one or the other).
  17. Avoid query strings as much as possible.
  18. Use a “/” in the URI to express parent-child relationships.
  19. REST URIs should be static in nature so that when the resource changes or the implementation of the service changes, the link stays the same to allow bookmarking.
  20. Users of REST resources should not derive metadata from the URI.
  21. Response payloads in REST should be simple, human readable and connected.
  22. Give client applications the ability to request a specific content type best suited for the client application.
  23. All resources transferred over REST must be marked cacheable, or non-cacheable (at minimum).
  24. REST deployments should be layered.
  25. Use a resource based approach for mobile devices.
  26. Use HTTP error codes along with suitable additional information in a header like X-Application-Error-Code: for differentiating multiple mappings to the same code used for REST exception.
  27. Do not return empty XML documents in case of error.
  28. Always return a response document.
  29. All REST responses should return a request ID like for troubleshooting purposes.

http://wp.me/p2MYVz-1c

Booker Showers

Page 1 of 212