I’ve used the slogan “Reduce, Recycle, Reuse” before but in a different context. It is something I’ve been thinking about lately in an enterprise architecture context. I don’t know when Reduce, Recycle, Reuse was termed and the all knowing Wikipedia couldn’t help pinpointing its origin but at its core it is about rethinking waste. If we relate this mantra to enterprise architecture the meaning doesn’t change much. EAs rethink wasteful investments. These are investments that don’t help the business achieve its objectives. I propose that EAs need to reduce risks, recycle ineffective processes and reuse learned value.
EAs should have visibilities into corporate risks. Let’s not paint all risks as something that is imminent and negative but more of an opportunity to course correct and prepare for something that is not desirable in relation to achieving corporate objectives. For example, well run companies have a healthy pool of talented, trained and promotable leaders to accommodate a variety of leader transitions. This is a leadership risk mitigation strategy. There are many areas in which EAs can help corporations accommodate for multiple types of risk mitigation strategies. EAs should work with corporate strategists to plan for possible future events e.g. market changes like a new desirable taste in a cracker or emergent competitors that undercut costs. If the EAs know in advanced that a certain business event like the acquisition of a supplier could occur then they should plan for certain systems and processes to require a bit more agility to promote a more rapid acquisition. Another example, the public relations arm of a company starts to realize some notions of impending regulatory change. EAs should have the opportunity to introduce some “what if” scenarios to help realize how those changes will affect the business and the systems that support the business. This scenario may give some short-term tangible benefits of pointing out some weak capabilities that need improvement, e.g. report and data warehouse. These are examples of how EA can help reduce corporate risks.
There are areas in business where something isn’t a risk but may be nearly ineffective. EAs can find infectivity when the cost of a part of the business is not equal to the shareholders value plus the risk potential. EAs should have mechanisms to identify ineffective business processes that are candidates for recycling. I’ve seen parts of a business that are ineffective against the corporate mission. You can spot them when you ask why something exists and the answer is because we’ve always done it that way. EAs can work with business SMEs and redesign the necessary business process to align with the corporate mission. For example, I witnessed some craziness with SOX controls in 2002. Well, in 2004 some of the large control processes and system that were put in place were very costly but and some process weren’t required. So, the EA team worked with the process owners and had them implement the process on more effective systems and in the more effective part of the business. So the SOX enforcements processes were recycled into more appropriate areas of the business and on more effective systems.
Lastly, EAs should possess the ability to help reuse successful business processes. I’m sure the Ray Kroc (Mcdonald’s Leader) went through multiple French Fry assemble processes before he found the one that was successful enough to replicate. This is a fairly simple concept but can be difficult for company’s managers to accept because of politics, you know the win at all costs mentality. EAs should be able promote win/win solutions. For example, let say a company has multiple costly systems to support nearly similar business processes, Order 4 Cash for instance. In this scenario EAs may suggest that the more costly processes fold into the more effective system. As long as the EAs have the support of company leadership and the EAs display objectivity via following governing principles and company standards, the business community should be able to effectively unite the processes.
By no means is this all that EAs do but I feel this should be more prominent in the EAs scope of work. I propose EAs sanction the mantra of Reduce, Recycle and Reuse. EAs should be closely aligned with the business in its strategy to help find and define its risk mitigation strategies. EAs should have metrics in place to find opportunities to help business’s productivity. EAs should be able to find the productive areas of the business to help replicate successes.
BTW: I just added a disclaimer to this site because i just read a company policy. In the spirit of this post I reduced corporate risk and reused some verbiage from a very smart person.
We’ve all done something with a piece of software that had adverse effects like a Blue Screen or even a silly popup that says nothing. Or recently we learned that if you hold the new iPhone with your finger in a certain area you lose your wireless signal. That would be a bummer if you were answering serious question. There are other examples of sad software bugs. One of many possible reasons these bugs appear is because there may not be adequate test coverage to all product capabilities.
A product capability is synonymous with product features. Product features are comprised of many product functions. When implementing Commercial Off the Shelf (COTS) software there is thinking that you do not need to test all the functions of the COTS because 1) it was already tested by the software manufacture and 2) typical project constraints (time, money & scope). I used to think similarly. However, since implementing Content Management Systems (CMS) for a decade, I found that not testing more of the functions in a system can be harmful to the end solution. In testing terms, we would say we want to increase the function / test coverage ratio.
Typical testing on a project is called functional testing. Functional testing, tests business documented features, e.g. create content, that are written into some sort of systems documentation. During the content creation scenario, we test a variety of functions, e.g. menu -> file -> new, WYSIWYG editor and a save function. In addition, we probably tested some immediately ancillary functions like a cancel link. As a side note, the ancillary tests are called alternative scenarios. As I have noticed this is usually where testing stops. Bearing a positive test result, the testers and business believe that the feature they tested acts as expected. However, we did not test other ways the systems allows for content creation.
Very relevant with content management systems, many product functions perform similar actions against content. For example, there can be several ways to perform a content creation function, e.g. “My Work area,” “My workflows,” “My Content” and “Watched Content.” Each navigation to the content create function may act differently, e.g. “My Workflows” may produce a new piece of content form with limited form fields while the “My Work area” content create function may display workflow options. Stakeholders of the content management process will expect that if the software allows for the edition of content through these multiple ways that each content create function would perform similarly. Testing all these “extra” function is called capability testing. Capabilities are functions available to users that were not explicitly written in the system specifications. There are some testing techniques that can help increase your testing coverage, e.g. combinatorial and pairwise testing but that is a start of a different post.
Even though, I used a simple example there are some extreme results to not testing all capabilities. For example, deployed content to production websites that was not reviewed by the correct persons. This deployment could have posted a 10-k without CxO approval.
Capability testing is difficult to test because testers will need to hunt for these special forms of product features. It is important that test scripts are written to cover many if not all capabilities of the system not just the ones including in functional testing as per system specification. This thoroughness has implications to both the test process and the entire project. Project teams need to work with stakeholders to make sure that capabilities in the system are appropriate. It is not uncommon for the project team to discover these “extra” capabilities and then turn them off. The trick is to make sure you find them all because if you don’t the users will.
Seth Gottlieb, Content Here, published a very pointed report for specific types of sites implemented in Drupal. I am continuous impressed by Drupal. Seth reviews some sites like fast company and the onion and both are definitely interesting, high impact Drupal sites. Maybe a little out of scope for Seth’s report but I have always been impressed with what SonyBMG does with Drupal. For all music fans check out myplay. Additional, documented on the drupal site is a breakdown of the myplay site.
Here is an image from the my play breakdown
Reading the CMSWatch today, I read something that I have been wondering about for nearly 6 years. Oracle has finally acquired Sun. Sun has set but hopefully it will not be eclipsed. What an interesting deal. Oracle will now own systems infrastructure, including SAN, Server, and many other hardware systems. They own the Sun JRE and JRocket, Three java development IDE’s with Oracle Weblogic Workshop, Oracle Developer and now NetBeans. They will support windows, solaris, open solaris, redhat, and unbreakable linux. Oracle now has the oracle database and all its flavors as well as innodb, Berkley, and they finally got mysql. Not to mention own all the Java trademarks.
This is very interesting for me because now one company now owns the software for many of the systems that I have, am implementing. Do not get me wrong; I also work with software from Big Blue’s and other open source products but my core experiences have been with Sun, Oracle, and BEA. Now it is all Oracle.