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.


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.


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.


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
  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.


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.


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 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.


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.


Booker Showers

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


  1. core decisions about business or technological functionality within the enterprise
  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.



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.


Booker Showers

Tune Your Information

Tune Your Information For An Effective Mobile Strategy





Adaptability on an enterprise scale







Booker Showers

Real Time Strategy

Operate in Real-Time – A Mobile Real Time Strategy






Comprehensive information and integration








Booker Showers

How to identify objects as REST Resources

How to identify objects as REST Resources


Assuming the reader has an idea of the REST design philosophy, rampant confusion exists on what is exactly a resource.  Much debate exists on how to identify and/or classify Internet HTTP objects as REST resources.  A resource is the data end point of a URI (e.g., music.taliferro.com/artists/calima-shatiday/).  Data is emphasized because REST resources should be a stateless data representations that can be bookmarked.  It’s important to understand this design philosophy when creating a REST resource.  This idiom is often ignored and puts a REST design in significant peril.

I have also seen many SOAP implementations shoe-horned into REST which only leads to abstruse REST structure.

So how are these resources manipulated?  REST resources are manipulated in 2 ways, through the HTTP verbs (PUT=UPDATE, POST=ADD, GET=RETRIEVE, DELETE=DELETE) and custom REST objects called components.

Components act upon Resources.  (What Roy Fielding calls components some people call controllers. REST components perform actions on a resource by using a representation to capture the current or intended state of that resource and transferring that representation between components.) This is an important concept to understand, because it is the foundation of good REST design.

A good REST design will define data elements as the resources, use PUT, POST, GET and DELETE to manipulate the data.

An easy way to design REST is to look at the landscape and divide your nouns and verbs.  The nouns are your resources and the verbs should fit under PUT, POST, GET and DELETE and act as your controllers or actions verbs.  If you can remember this simple design constraint, the limitation will assist in creating a decent REST design.


Booker Showers

Service Mediation

Understanding Service Mediation


Mediation is a metaphor used to describe brokering service capabilities.  A skilled developer can build a mediation model on top of any provider’s software to deliver services in a controlled and efficient manner.

What problem does mediation solve?

Customers want access to company services. When customers sign up for a service via a website the customer does not like to wait to use the service.  Additionally, when a customer signs up for several services at once they usually want immediate access to the services.

Suppose the following services are provided by a company⎯audio streaming, online billing, content downloading, self service support, and 3rd party apps.  Each of the services has its own infrastructure and are managed by different departments.  How can  customers gain access to multiple services immediately after they sign up?  Service Mediation.

Service mediation is the mechanism used to stitch together various system services and present to a customer one unified service.

However, service mediation is not limited to internal infrastructure type services accessible to customers. Service mediation also applies to REST resources a company wants to make available to internal and external developers.

Understanding Service Mediation

Services are composite functions built by combining multiple Factory Assistants.  A composite service consists of services drawn from several different factories. The components may be individual services, functions from within other applications, or entire systems.

Mediator provides centralized Business Support by integrating process flows and business logic. Main also provides synergy across services, users, and subscriptions. Moreover, this synergy is dynamically created, configured, and provisioned by using a set of profile definitions and policies.

Sentry is the access point. Software on this layer provides security to USM capabilities from a user interface.

Factory assistants generally provide a set of building blocks common to all services.


Booker Showers

Page 1 of 212