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.

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.


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

Production Best Practices

A programmer should not expose resources within a REST initiative in a “bottom-up” ad hoc manner. Bottom-up development is inherently driven by immediate project needs. For example, how you solve a specific problem with a specific implementation (often driven by the influence of existing applications and associated behaviors masquerading as true business requirements).

What happens when an organization defines and implements REST with the mindset described? The REST implementation simply becomes layered with more spaghetti code of a different form that does not improve business process flexibility. Consequently, a monolithic application in a different technology is implemented often with disappointing results.

To achieve success, a programmer should not define REST in a “top-down” manner. Top-down business process analysis can lead to either “analysis paralysis” – continual refinement of a model hoping to reach perfection (which never comes), or “Big-Bang” projects – trying to define and implement everything at once. Either approach usually creates disastrous consequences (a combination of “death march” projects, and cost, and schedule overruns).

What do organizations need to make progress? A coarse-grained business model driven by key business processes. Not all key business processes may apply but definitely a representative set of high-priority processes to start. Architects and business analysts should collaborate to build an applicable model by extracting key business processes to define a normalized set of functions. Next, group functions together based on behavioral affinity as a straw-man set of initial, target resource definitions.

Resultantly, we have a useful framework for the “real work” – detailed analysis, design, and REST implementation needed for our current set of prioritized projects. Based on business process (and project) prioritization, we identify the needed resources from our business reference model and formalize the definition for the prioritized resources. Ideally, each resource should be driven by requirements extracted from at least two separate processes. Designing a REST resource based on a single use case may result in a fragile, and narrowly defined implementation lacking the flexibility necessary to meet the next set of prioritized projects. Formalization efforts are likely to result in modifications to business architecture – which is fine! We can iteratively enhance the architecture as progress is made towards a successful REST implementation.

Booker Showers

Corporate Culture

Influencing REST Behavior and Relationships

To determine and shape organizational behavior that sustains REST efforts over time is often the work of change management specialists. However, conceptualizing the role of REST is easier if we examine the intersection of major influences, such as organizational and individual characteristics. Some influences include:

  • Corporate culture
  • Major decision-making processes
  • Budgeting processes
  • Incentives and penalty structures
  • Compensation linkages to corporate goals and mantras
  • Portfolio management processes
  • Architecture process (definition, acquisition, implementation)
  • Architecture practice (solutions development)
  • Corporate performance metrics⎯return on invested capital (ROIC), revenue and market share growth, cost controls
  • Promotion and advancement criteria

Key factors in the context of REST determine how effective process changes are within an organization. Understanding key process relationships helps a governance board design better REST resources.

For example, the relationship of the budgeting office to project execution helps align budget oversight with the project. Without proper budget-to-project alignment, teams might build project-centric resources. Unfortunately, project-centric resources do not fit the broader needs of an organization. Another example, the relationship between the procurement office and enterprise architecture. Does the acquisition process reflect the goals and standards of the Enterprise Architecture (EA) organization? If not, how can the acquisition process change to better reflect goals and standards?

Another critical relationship is between EA and project or solution architecture, which connects architecture through governance to downstream activities. If there is a disconnect between enterprise architecture and architecture designed at the project level, the result may produce disjointed architecture.

The internal relationships reflect how organizational culture and stakeholder influence converge to either facilitate or hinder REST implementations. There are no easy answers. However, the development of complementary and supportive relationships increase the possibility of successful REST initiatives.

REST Governance Separation of Concern

REST initiatives, in conjunction with other architectural approaches, force IT organizations to recognize teams producing resources are not likely to be the consumers of those resources. Unlike traditional application development, REST is built upon the premise that a set of resources can be used within a wide range of applications. REST depends on production and consumption separation.  The distribution vehicle must allow resource producers to communicate with resource consumers. Observing and consulting for many REST implementations, we have defined the production, distribution, and consumption concerns:

Production: Identification of and governance over the development and maintenance of existing and newly defined candidate reusable resources

Distribution: Publication of those resources for widespread dissemination to potential resources consumers

Consumption: Discovery of and governance over the appropriate use of resources within application development projects

Executing responsibilities within governance concerns through manually defined and managed procedures is technically feasible. However, essentials for IT organizations of any size to build a successful REST implementation include solving political and organizational issues. In addition, selecting appropriate tools such as a resource, repository/registry to automate governance and distribution resources also help build successful REST implementation.

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

Cloneable Interface Design

A cloneable interface design often requires a clear separation between a type and its implementation. Often it is unavoidable to provide a public clone() operation for such a type when the type is used as part of the state of an object.  A cloneable interface design relies on the following factors:

Cloneable Interface Design Forces and Facts

  1. Accessor methods in Java should return a copy of internal state variables instead of references to the internal variables – in order to maintain an object’s integrity
  2. When values given to constructors are to become part of the state of an Object and should be copied instead of just referenced.
  3. There are no constructors available in an interface declaration, so a “copy constructor” cannot be declared.
  4. The visibility of a clone() method needs to be public to allow arbitrary client classes to clone the object

Example of Problem:

public interface State {
// some operations

public class C { public C (State s) { 
state = new State(s); 
state = s; 

public State getState() { 
return state; 

protected State state; 


public interface State extends java.lang.Cloneable {
        // some operations
public Object clone();

public class C { public C(State s) { 
state = (State)s.clone(); 

public State getState() { 
return (State)state.clone(); 

protected State state; 

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.

Booker Showers

Strategic Focus

Is Lack of Strategic Focus Killing Your Business?

Instead of focusing on improving the processes that directly affect core business competency, many businesses invest enormous amounts of money, too much time, and human effort on software engineering and reengineering.

Valuable capital assets are spent on maintaining and upgrading systems that hinder business continuity and lack future adaptability. Executive strategic direction and employee activities remain disconnected. Consequently, related business functions fail to provide useable information that can be applied to achieve organizational goals and objectives.

Strategic Focus Aided By Integration

Smart business management teams utilize integration as a portal to their business processes; thereby, creating real-time snapshots of the business.

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

Rhythm Section

The Rhythm Section (Frameworks)



Getting applications up and running in the shortest amount of time is critical these days.  This involved reducing the learning curve and implementing many concrete and final classes.  The following paragraphs examine the importance of framework design.


Frameworks reuse both design and code. Aspects of a design, such as the kinds of objects, are easily described by code. Other aspects are not described well by code, such as invariants maintained by objects in an ensemble. The fact that aspects of a framework are not expressed well as code makes frameworks harder to understand than abstract classes. A design must emphasize its details of a at the expense of others. A framework concentrates on describing object that make up the program and how they interact.

Dataflow is de-emphasized, but the communication between object is emphasized. Since frameworks provide abstract algorithms, users of a framework usually ignore the details of these algorithms and concentrate on designing and combining objects. The concept of a framework is harder to understand than that of an abstract class. Abstract classes can be defined either by how to recognize them or how to use them. Unfortunately, there is no simple way to tell whether a set of classes is a framework, so frameworks tend to be defined on how they are used.

The important classes in a framework, such as of Model/View/Controller, are usually abstract. Like Model/View/Controller, a framework usually comes with certain concrete subclasses of the classes in the framework. No component library is perfect to derive new concrete subclasses of the abstract classes in the framework. A good component library is valuable in addition to the framework, the essence of a framework is not the component library, but the model of interaction and control flow among the objects.

Frameworks are informally defined early as a set of objects and how they interact. Most the object ­oriented frameworks are specified by informal documentation and a set of (usually) abstract classes that represent the objects. The classes give the operational specification of how objects in the framework work together.

Given a specification language for describing the behavior of a set of objects, a framework would be a function from the set to constrain the behavior. For example, the Model/View/Controller framework would be a function from the three objects in a MVC trio: the view has a function from the state of the model to an image to invariants like the image on the screen inside a view’s bounding box is its function applied to the state of the model, and to operation sequences like whenever the controller changes the state of the model, it performs the operation on the view, which will redraw the screen. Note that a framework can define both the invariant and the outline of the algorithm.

Frameworks rely on undefined properties of the objects, such as the function from the state of the model to the image. A framework is filled out by selecting objects according to how they define these properties. The objects in a framework often place additional constraints on each other. Views (controllers) often use specialized operations to read (change) the state of a model. The major problem with expressing frameworks in a programming language is that it is hard to learn the constraints that the framework imposes on a program. The major advantage of expressing a framework as a program is that the algorithms and data structure of the program are automatically reused by every instantiation of the framework. There is usually an abstract class for each component in the framework. The algorithms and data structures that are reused are usually defined by these abstract classes. Each subclass of the abstract class defines a kind of component that fits into the framework, and they inherit much of their implementation from their abstract superclasses. This makes it easier to develop a library of components that can be mixed and matched within a framework.

A framework would be described both operationally and in terms of the constraints that it places on its components. This would not only provide code reuse, but make it easier to learn how objects in the framework interact. A framework reuses analysis, design, and code. It reuses analysis because it describes the kinds of objects that are important and how a large problem should be broken down into smaller problems. It reuses design because it contains abstract algorithms and describes the component interfaces that the programmer must implement and the constraints that any implementation must satisfy. It reuses code because it makes it easy to develop a library of compatible components and because the implementation of a new component can inherit most of its implementation from an abstract superclass. All of these are important, though in the long run it is probably the analysis and design reuse that provide the biggest payoff.

A framework hides the parts of the design that are common to all instances, and makes explicit the pieces that need to be customized.

A framework is most valuable when the part of the design that is hidden is the part that programmers find hardest to understand.

A class that is not abstract is concrete. In general, it is better to inherit from an abstract class than from a concrete class. A concrete class must provide a definition for its data representation, and some subclasses will need a different representation. Since an abstract class does not have to provide a data representation, future subclasses can use any representation without fear of conflicting with the one that they inherited. Creating new abstract classes is very important, but is not easy. It is always easier to reuse a nicely packaged abstraction than to invent it.

A programmer usually tries to create a new class by making it a subclass of existing class, since this is less work than creating a class from scratch. This can result in a class hierarchy whose top­most class is concrete. The top of a large class hierarchy should almost always be an abstract class. As a programmer gains experience, they will then try to reorganize the class hierarchy and find the abstract class hidden in a concrete class. The result will be a new abstract class that can be reused many times in the future.

An example of a class that needs to be reorganized is View, which defines a user interface object that controls a region of the screen. A view might have many subclasses, but is concrete. A careful examination will reveal a number of assumptions made in a view that most of its subclasses do not use. The most important is that each view will have subviews. In fact, most subclasses of a view implement views that can never have subviews. Quite a bit of code in a view deals with adding and positioning subviews, making it very difficult for a beginning programmer to understand the key abstractions that a view represents. The solution is simple: split View into two classes, one (view) of which is the abstract superclass and the other (view WithSubview) of which is a concrete subclass that implements the ability to have subviews. The result is much easier to understand and to reuse.

Booker Showers

Page 2 of 512345