Prefabricated Skyscrapers

Eleven years after the 9/11 destruction of the World Trade Centers, we are still waiting for the new Freedom Tower to go up.

Yes, there were political disputes on what type of building and memorial would be erected, what security features would be included, what the insurance would pay, and so on.

But then there is also just the shear length of time it still takes us to build a building—a skyscraper, but also other smaller and simpler structures too.

Wired Magazine (October 2012) is reporting on a new method for building construction coming out of China.

Unfortunately, China has been known for some time for unsafe building practices—perhaps doing things on the cheap and then paying for it in terms of consequences later.

Yet, this new technique promises to increase safety, as well as speed, while lowering costs.

If you are willing to give up some building pizzazz, then Broad Sustainable Building is perfecting the prefabricated skyscraper—and these have tested “earthquake-proof” for a 9.0 quake, cost only $1,000 per square foot (versus $1,400 normally)—a 40% savings, and a 30 story building can be built in just 15 days!

Now, Broad says that they even want to erect a 220 story mega skyscraper in 6 months—by March 2013.

Here’s how they do it:

• Identical modules—each section is prebuilt in identical modules in the factor.
• Preinstalled fixtures—Pipes and ducts are threaded through each module in the factory for AC, hot and cold water, and waste.
• Standardized truckloads —with two stacked pallets, each pallet has everything needed to erect a section including wall panels, columns, ducts, bolts, and tools.
• Lego-style assembly—sections are lifted by crane and installed quickly in snap-like fashion, including pipes and wires.
• Slotted exterior—heavily insulated walls and windows are hoisted by crane and slotted into the exterior of the building.

Aside from a standardized, consistent, high quality building—it is energy efficient, generates less than 1% the construction waste, and is safer to construct.

As with the rest of the industrial age, this is just the first step in mass producing—in this case buildings—and like the Ford Model T, which came in only one color black and evolved to meet consumer tastes and needs, these building will soon come in all sorts of shapes and sizes but at a fraction of the cost and the time to build.

This is enterprise architecture applied to building architecture making use of modular design and construction, standardization, and consolidated engineering, manufacturing, and assembly to develop next generation products. 

(Source Photo: Minna Blumenthal)

Prefabricated Skyscrapers

Work Off Of Standards, But Stay Flexible to Change

Interesting book review in the Wall Street Journal (18 January 2012) on Standards: Recipes for Reality by Lawrence Busch.
Standards are a fundamental principle of enterprise architecture, and they can mean many things to different people--they can imply what is normal or expected and even what is considered ethical.
Reading and thinking about this book review helped me to summarize in my own mind, the numerous benefits of standards:
- Predictability--You get whatever the standard says you get.
- Quality--By removing the deviation and defects, you produce a consistently higher quality.
- Speed--Taking the decision-making out of the routine production of standardized parts (i.e. we don't have to "reinvent the wheel each time"), helps us to move the production process along that much faster.
- Economy--Standardizing facilitates mass production and economies of scale lowering the cost of goods produced and sold.
- Interoperability--Creating standards enables parts from different suppliers to inter-operate and work seamlessly and this has allowed for greater trade and globalization.
- Differentiation--Through the standardization of the routine elements, we are able to focus on differentiating other value-add areas for the consumer to appeal to various tastes, styles, and genuine improvements.
While the benefits of standards are many, there are some concerns or risks:
- Boring--This is the fear of the Ford Model-T that came in only one color, black--if we standardize too much, then we understate the importance of differentiation and as they say "variety is the spice of life."
- Stagnation--If we over-standardize, then we run the risk of stifling innovation and creativity, because everything has to be just "one way."
- Rigidity--By standardizing and requiring things like 3rd-party certification, we risk becoming so rigid in what we do and produce that we may become inflexible in addressing specific needs or meeting new requirements.
The key then when applying standards is to maximize the benefits and minimize the risks.
This requires maintaining a state of vigilance as to what consumers are looking for and the corollary of what is not important to them or what they are not keen on changing. Moreover, it necessitates using consumer feedback to continuously research and develop improvements to products and services. Finally, it is important to always be open to introducing changes when you are reasonably confident that the benefits will outweigh the costs of moving away from the accepted standard(s).
While it's important to work off of a standard, it is critical not to become inflexible to change.
(Source Photo: here )

Work Off Of Standards, But Stay Flexible to Change

An Apple Turnover and Enterprise Architecture

CIO Magazine, 15 July 2008, has an interesting article called “A Tangled Paths for Macs in the Enterprise.”

The question posed: is it time to switch our enterprise from PCs to Macs?

“Apple—a synonym for awe-inspiring design and coolness—the antithesis to stodgy old corporate technology…the iPhone’s favorable reception portends something more: Some believe it could usher in the era of a more enterprise-friendly Apple.”

Macs have come a long way…

“Macs have increasingly become the consumers’ brand of choice. Apple shipped 2.3 million Macs in the second quarter of 2008, which represents a 51 percent growth for the product.”

Will Weider, the CIO of the Ministry of Health Care and Affinity Health System compares “Macs to luxury cars in a PC world of Chevy Impalas.”

Aside from the design wow factor and their innovativeness, historically, Macs are safer from viruses and have lower maintenance costs. All good reasons to consider an enterprise roll-over to Macs.

From a User-centric perspective, Apple understands how people use technology and their products seem to be the choice many would like to make!

What is holding Apple back in the enterprise?

Consumer-orientation: “Business adoption of Macs and Apple software has been sluggish, perhaps, in part, because this is a low priority for Apple. While Apple, of course, deals with businesses, it remains a consumer-oriented company, by the numbers.”

Technology refresh schedule: “Apple does not provide technology roadmaps…what’s worse they make their hardware incompatible with the previous version of the operating system, and their schedule is impossible to keep up with.”

So what is an advantage to Apple in the consumer marketplace—catering to consumer needs and rapid innovation—is a boondoggle in the business environment. Ah, a double edged sword indeed.

Further, a wholesale switch-out to Apple in a Windows shop typically involves desktops, servers, operating systems, and reworking oodles of legacy systems; this is quite a costly endeavor that is not easy to justify in resource constrained organizations.

Further, one of the core principles of enterprise architecture is standardization in order to reduce complexity and achieve cost-efficiencies, so introducing new platforms or a mixed environment is frowned upon.

In the future, as more and more applications become commoditized and moved to the Internet, thereby reducing the cost of transition to Apple, perhaps Apple will have a better chance to challenge Microsoft on the business playing field.

An Apple Turnover and Enterprise Architecture

SOA Liberates Productivity

Harvard Business Review (HBR), June 2008, has a wonderful article (by Ric Merrifield, Jack Calhoun, and Dennis Stevens) on how SOA is “the next revolution in productivity.”

SOA defined:

“It is becoming possible to design many business activities as Lego-like software components that can be easily put together and taken apart…service-oriented architecture [is] a relatively new way of designing and deploying the software that supports a business activity.”

With SOA, business activities can be accessed via the Internet through web services. Rather than build proprietary, redundant business services, our organizations can re-use standardized services, developed internally or outsourced, as components that plug and play into our enterprise.

“Virtually all large companies suffer from an enormous duplication of activities; they continue to create and perform hundreds of non-core tasks that would ideally be outsourced; and they are spending exorbitant amounts on IT projects in order to support redundant and nonstrategic operations and to update core processes.”

How does this differ from other quality improvement initiatives?

Prior quality improvement efforts like Total Quality Management (TQM) and Six Sigma have focused on reducing waste and defects and eliminating unnecessary tasks and integrating disparate ones.

“For the most part, however, reengineering has involved recasting processes and the information systems that support them in a proprietary, rather than a standardized, form—that is, customized for individual organizations. Such designs make it difficult and expensive for business to share, consolidate, and change processes.”

Now with the Internet and web services, we can access standardized services that can be shared and re-used throughout disparate business units in the same enterprise and across organizations globally.

The result is business units and organizations that can simply plug and play to make use of needed services, eliminating proprietary processes and redundant systems and enabling outsourcing of noncore mission functions and activities and easier upgrades to new superior services as they come online.

What are some of the issues holding SOA back?

Firstly, many people do not truly understand SOA, what it is, what benefits are possible, and what the challenges are to doing it right.

Second, SOA is viewed by many executives as yet another hype or bubble that will cost the enterprise lots of money, but fail to provide the promised return. So, they are wading into SOA only enough to “deploy it in a limited fashion,” but without first rethinking the design of their business.” However, to really reap the benefits of SOA, organizations need to transform from “collections of proprietary operations into a collection of standard plug-and-play activities,” and this requires redesigning not only IT systems, but operations.

In designing SOA-based processes, the unit of analysis and reengineering is no longer the task (as in Frederick Taylor time and motion studies of the late nineteenth century) or the department, or even the division. “In the age of the Internet and SOA, the unit of analysis is not a company’s way of conducting its operations at all; it is the primary purpose or desired outcome of each activity no matter how that activity is accomplished.”

Where are we today with SOA implementation?

“Unfortunately, few companies are using SOA to create more productive and focused organizations or to slash costs by purging duplicative operations and technologies. They are not revisiting the fundamental design of their operations.”

To overcome the obstacles in reaching SOA enabled organizations, we need a strong dose of enterprise architecture to identify and decompose our performance outcomes we are driving toward, the business processes to achieve these, the information required to perform these, and the systems that can serve them up.

According to HBR, our business model activities can be categorized into the following for SOA implementation:

• Primary (I would call this core mission)—those that should be kept in-house and are “top priority of programs to improve operations and technology” (i.e. through business process improvement, reengineering, and the introduction of new technology).
• Shared—those that “can be shared with other divisions” (i.e. through common solutions).
• Shifted—those that “can be transferred to customers, suppliers, or operational specialists” (i.e. outsourced).
• Automated---those that can be “automated so they can be turned into web services.”

All but the primary activities are ripe for SOA-based enhancements. And according to HBR, only about 20% of activities are primary, so that leaves plenty of room for a SOA plug-and-play.

The idea is to cease defining our noncore mission processes and activities as proprietary, requiring elaborate and expensive customized solutions for these. Instead, we should use standardized “swapped, bought, or sold” services. Then, we can truly focus our business process reengineering and IT investments on our organization’s core mission activities—working to to differentiate ourselves and develop unsurpassed competitive advantage.

SOA Liberates Productivity

Building Enterprise Architecture Momentum

Burton Group released a report entitled “Establishing and Maintaining Enterprise Architecture Momentum” on 8 August 2008.

Some key points and my thoughts on these:

• How can we drive EA?

Value proposition—“Strong executive leadership helps establish the enterprise architecture, but…momentum is maintained as EA contributes value to ongoing activities.”

Completely agree: EA should not be a paper or documentation exercise, but must have a true value proposition where EA information products and governance services enable better decision making in the organization.

• Where did the need for EA come from?

Standardization—“Back in the early days of centralized IT, when the mainframe was the primary platform, architecture planning was minimized and engineering ruled. All the IT resources were consolidated in a single mainframe computer…the architecture was largely standardized by the vendor…However distributed and decentralized implementation became the norm with the advent of personal computers and local area networks…[this] created architectural problems…integration issues…[and drove] the need to do architecture—to consider other perspectives, to collaboratively plan, and to optimize across process, information sources, and organizations.”

Agree. The distributed nature of modern computing has resulted in issues ranging from unnecessary redundancy, to a lack of interoperability, component re-use, standards, information sharing, and data quality. Our computing environments have become overly complex and require a wide range of skill sets to build and maintain, and this has an inherently high and spiraling cost associated with it. Hence, the enterprise architecture imperative to break down the silos, more effectively plan and govern IT with an enterprise perspective, and link resources to results!

• What are some obstacles to EA implementation?

Money rules—“Bag-O-Money Syndrome Still Prevails…a major factor inhibiting the adoption of collaborative decision-making is the funding model in which part of the organization that bring the budget makes the rules.”

Agree. As long as IT funding is not centralized with the CIO, project managers with pockets of money will be able to go out and buy what they want, when they want, without following the enterprise architecture plans and governance processes. To enforce the EA and governance, we must centralize IT funding under the CIO and work with our procurement officials to ensure that IT procurements that do not have approval of the EA Board, IT Investment Review Board, and CIO are turned back and not allowed to proceed.

• What should we focus on?

Focus on the target architecture—“Avoid ‘The Perfect Path’…[which] suggest capturing a current state, which is perceived as ‘analyze the world then figure out what to do with it.’ By the time the current state is collected, the ‘as-is’ has become the ‘as-was’ and a critical blow has been dealt to momentum…no matter what your starting point…when the program seems to be focused on studies and analysis…people outside of EA will not readily perceive its value.”

Disgree with this one. Collecting a solid baseline architecture is absolutely critical to forming a target architecture and transition plan. Remember the saying, “if you don’t know where you are going, then any road will get you there.” Similarly, if you don’t know where you are coming from you can’t lay in a course to get there. For example, try getting directions on Google Maps with only a to and no from location. You can’t do it. Similarly you can’t develop a real target and transition plan without identifying and understanding you current state and capabilities to determine gaps, redundancies, inefficiencies, and opportunities. Yes, the ‘as-is’ state is always changing. The organization is not static. But that does not mean we cannot capture a snapshot in time and build off of this. Just like configuration management, you need to know what you have in order to manage change to it. And the time spent on analysis (unless we’re talking analysis paralysis), is not wasted. It is precisely the analysis and recommendations to improve the business processes and enabling technologies that yield the true benefits of the enterprise architecture.

• How can we show value?

Business-driven —“An enterprise architect’s ability to improve the organization’s use of technology comes through a deep understanding of the business side of the enterprise and from looking for those opportunities that provide the most business value. However, it is also about recognizing where change is possible and focusing on the areas where you have the best opportunity to influence the outcome.”

Agree. Business drives technology, rather than doing technology for technology’s sake. In the enterprise architecture, we must understand the performance results we are striving to achieve, the business functions, processes, activities, and tasks to produce to results, and the information required to perform those functions before we can develop technology solutions. Further, the readiness state for change and maturity level of the organization often necessitates that we identify opportunities where change is possible, through genuine business interest, need, and desire to partner to solve business problems.

Building Enterprise Architecture Momentum

Learning from the Private Sector and Enterprise Architecture

There is a terrific article in ComputerWorld, 17 July 2008, called “Pentagon’s IT unit seeks to borrow tech ideas from Google, Amazon, other companies.”

Defense Information Systems Agency (DISA) provides IT solutions to the Department of Defense. So what DISA does has to be state-of-the- art and best practice 24x7x365. Their mission depends on it!

To keep ahead of the curve, John Garing, DISA’s CIO and a retired Air Force colonel has been visiting with top tier private sector companies like Google, Amazon, UPS, Sabre, and FedEx to identify their best practices and incorporate them.

What has DISA learned from the private sector?

1. Cloud Computing

According to Garing, cloud computing is “going to be the way—it has to be. We have to get to this standard environment that is provisionable and scalable.”

To this end, “DISA has begin deploying a system [Rapid Access Computing Environment (RACE)] that is similar architecturally to Amazon’s Elastic Compute Cloud (EC2) technology, a web-based computing service that enables users to quickly scale up their processing capabilities.”

Using RACE, a soldier in the field will be able to use a client device (like a PDA) with web support and “dynamically access a wide range of information sources and meld together data,” such as blue force tracking, mapping of combatant locations, identification of aid stations, fuel and ammunition supplies, and so forth.

2. Elastic and flexible

DISA has to be prepared to handle the unexpected and this means they need to be able to flexible to meet a mission need or fight a war or two. Garing has found that companies like Amazon and Sabre have built their IT infrastructures to enable “elasticity and flexibility.”

3. Competing for business

Like the private sector that competes for market share, DISA sees itself and operates “like a business and produce[s] an attractive offering of IT services at a competitive price. They recognize that they “compete for the business it gets from other military agencies, which in some cases have options to use private-sector IT service providers.”

4. Process-driven and Speedy

Like enterprise architecture, which looks at both business processes and technology enablement, Garing is “interested in the processes that companies use to deploy technology, not just their technology itself.” DISA wants to learn how to speed an idea to a service in just a few months as opposed to the years it often takes in DoD.

DISA is learning that cloud computing will enable increased standardization through a “standard suite of operating platforms” as well as increased “deployment speed and agility.”

By being open to learning from the private sector, Garing is leading an enterprise architecture that is making for a better and more capable DoD.

Job well done DISA and a shining example for the rest of the federal space!

Finally, learning is not a one-way street and surely the interchange between the public and private sector can lead to improvements for all.

Learning from the Private Sector and Enterprise Architecture

Architecting a Balance

As a child, we learn from our parents, teachers, and mentors, that too much of even a good thing is bad for you: be it sweets or hard work—in fact, just about anything taken to an extreme is deadly.

The lesson of finding a balance in life has been captured in religious and philosophical teaching about practicing a middle of the road or golden path approach in life. In architecture as well, developing a strong viable architecture is also premised on balancing conflicting demands and finding that delicate balance.

In simple terms, architecting a balance shows up in having to manage scarce IT resources. So that while on one hand, we may like to have the latest and greatest technologies to give us every edge, we have to balance to promise of those technologies with the cost involved. We do not have endlessly deep pockets.

Similarly, while on one hand, we it would be wonderfully customer-centric to provide each and every one of our customers the customized business processes and technology solution that they want, prefer, or are simply most familiar or comfortable using; on the other hand, we must balance the innovativeness and agility that our customers demand with the need to standard around enterprise and common solutions, which provide a more structured, deliberate, and lower cost base on which to service the enterprise.

As we know from childhood, it is not easy to find the “right” balance. That next bite of cotton candy tastes great going down and we won’t feel the stomachache till later that evening.

National Defense Magazine, November 2007, has an article about architecting a balance in the Coast Guard mission of maritime security, titled “License to Boat?”

The threats from small boating vessels are threefold:

1. Smuggling—“the use of a boat to smuggle people or weapons of mass destruction into the United States.”
2. Waterborne improvised explosive device (IED)—“that a boat will be used as a weapon itself by a suicide bomber” (such as the attack in 2000 on the USS Cole). “Imagine…the consequences of waterborne IEDs against passenger ships, against tankers, against port facilities themselves.”
3. Weapons’ platform—“boat used as a platform to launch a weapon, such as a short-range ballistic missle,” says Dana Goward, Director of MDA, at the U.S. Coast Guard

Despite these serious security threats, the article discusses the challenges of architecting a balance between increased security/maritime domain awareness (such as through requiring of boating licenses and/or automated identification systems for the more than 17 million small vessels that operate in U.S. waterways) and the desire to “ensure that future regulations don’t compromise boaters’ way of life or disrupt the flow of commerce.”

Of course, there is more than one way to skin a cat, so if security options don’t include boating licenses, Goward states, “the answer could be something as simple as a combination of rules, extra patrols, and increased monitoring on the waterways.”

When it comes to balancing competing interests, nothing is really simple. National Defense Magazine reports that in terms of maritime security, the Congressional Research Service (CRS) report on “Maritime Security: Potential Terrorist Attacks and Protection Priorities,” states that “terrorists are more likely to use small boats for waterborne attacks because they ‘satisfy the overwhelming terrorist requirements for simplicity,” Now, we need to continue architecting solutions that meet these security threats head-on, but at the same time preserve freedoms, our way of life, and support international commerce.

Creating balance between alternate views/needs is one of the biggest challenges, but also has the potential for some of the greatest benefits, because by striking a balance, we have the potential to satisfy the greatest number of stakeholders and optimize our ability to meet conflicting requirements. It’s easy to (as the Nike slogan says) “just do it,” but it’s hard to do it and not mess up something else in the process. For example, it’s relatively easy to do security, if you aren’t concerned with the affect on quality of life, commerce, and so on. However, this is not realistic.

Like all things in life, finding the right balance is an art and a science, and requires ongoing course corrections.

Architecting a Balance

Occam’s Razor and Enterprise Architecture

“Occam's razor (sometimes spelled Ockham's razor) is a principle attributed to the 14th-century English logician and Franciscan friar William of Ockham…The principle is often expressed in Latin as the lex parsimoniae (‘law of parsimony’ or ‘law of succinctness’)..This is often paraphrased as ‘All other things being equal, the simplest solution is the best.’… it is more often taken today as a heuristic maxim (rule of thumb) that advises economy, parsimony, or simplicity.’” (Wikipedia)

In Occam’s razor, “razor refers to the act of shaving away unnecessary assumptions to get to the simplest explanation.”

Thomas Aquinas made a similar argument in the 13th century: "If a thing can be done adequately by means of one, it is superfluous to do it by means of several; for we observe that nature does not employ two instruments where one suffices." (Pegis, A. C., translator (1945). Basic Writings of St. Thomas Aquinas. New York: Random House, 129.)

The principle of Occam’s razor is very applicable to enterprise architecture—how?

Occams razor is a call for simplicity, and this principle is a foundation for enterprise architecture in terms of consolidation, integration, and cost efficiency and takes specific form in terms of:

• Systems interoperability and component re-use
• Technology standardization and simplification

Paul O’Neill, the former Secretary of the Treasury was a true advocate of Occams razor and frequently asked “if not one, why not one?”

“The philosopher of science Elliott Sober once argued along the same lines as Popper, tying simplicity with ‘informativeness’: The simplest theory is the more informative one, in the sense that less information is required in order to answer one's questions.” (Wikipedia)

In this sense, Occam’s razor is a validation for User-centric Enterprise Architecture, which seeks to make information simpler, easier to understand, and generally more valuable and actionable to the end-user to enhance decision making. Moreover, Occam’s razor is also evident in User-centric EA application of principles of communication and design like simplifying complex information and maximizing use of information visualization in order to more effectively communication EA information.

Occams razor makes clear the need to transform from traditional EA’s development of “artifacts” that are often difficult for the user to understand and apply and instead develop more useful and usable information products and governance services.

Occam’s Razor and Enterprise Architecture

“Glocalization” and Enterprise Architecture

Glocal is a combination of the words global and local. It is a best practice in business where organizations conducts business operations globally, but tailor their offerings to meet local tastes and needs.

Essentially doing business glocally means that you are architecting your business to perform operations both effectively and efficiently—i.e. your business is doing the right thing by growing without geopolitical constraints and you’re doing it the right way, by being sensitive to the customers’ specific needs wherever they are located.

The Wall Street Journal, 1 May 2008, reports that “Kraft became the No. 1 biscuit maker in China by tailoring the Oreo to local tastes.”

“The Oreo has long been the top-selling cookie in the U.S. Market. But Kraft Foods, Inc. had to reinvent the Oreo to make it sell well in the world’s most populous nation.”

“Unlike its iconic American counterpart, the Oreo sold in China is frequently long, thin, four-layered and coated in chocolate. But both kinds of cookies have one thing in common: They are now best sellers.”

40% of Kraft’s revenue is internationally-based, so their strategy to go glocal is critical to improving their market share and profitability.

To increase growth at Kraft, the CEO “has been putting more power in the hands of Kraft’s various business units around the globe, telling employees that decisions about Kraft products shouldn’t all be made by the people at the Northfield, Ill. headquarters.”

Similarly, to market the Chinese Oreo’s, one of innovative things Kraft did was to have Chinese university students ride around on bicycles outfitted with wheel covers resembling Oreos and handing out cookies.

The CEO stated this was “a stroke of genius that only could have come from local managers. The more opportunity our local managers have to deal with local conditions will be a source of competitive advantage for us.”

Glocalization, the customization to local markets, is far removed from the original Ford Model T (the most influential car of the twentieth century according to Wikipedia) set in 1908 that was based on standardization and assembly-line production, rather than individually hand-crafted.

From an enterprise architecture perspective, going glocal and customizing (or tailoring) business products and services to local tastes is also quite the opposite of what most enterprise architects try to do, which is to standardize their products and services to increase interoperability, simplify the infrastructure and operations, and achieve cost-efficiencies.

So what is more important, standardization or customization?

I suppose it depends on your perspective. If you’re in operations, then standardization is the dominant factor in order to streamline business processes and achieve cost-efficiencies. However, if you’re in sales and marketing, then customization is key to market penetration and customer satisfaction.

This leads me to the role of the enterprise architect, which is to balance the conflicting needs of the organization and simultaneously drive standardization in business processes and technologies, but customization to local requirements for sales and marketing. So EA serves Oreos to everyone!

“Glocalization” and Enterprise Architecture

Port Security and Enterprise Architecture

[This Blog is based entirely on public information and represents my views alone and not those of the U.S. Coast Guard, Department of Homeland Security, or other Federal agency.]

Maritime and port security is critical to this nation, particularly after the events we witnessed on 9-11.

The largest border for the United States is our coastline at 95,000 miles. Moreover, there are approximately 361 major ports (according to the Council on Foreign Relations). Securing the maritime border is the purview of the United States Coat Guard (USCG), for which I have the privilege to work, and securing the ports is a collaborative effort between the U.S. Coast Guard, Customs and Border Protection (CBP), Department of Justice, and state and local law enforcement.

National Defense Magazine, April 2008, reports that “under project SeaHawk [a pilot project], port security officials during the past three years have developed the software, sensors, and communications infrastructure needed to maintain a 24/7 watch on this regional port [Charleston, S.C.]—the sixth largest in the United States.”

From an enterprise architecture perspective, the keys to the success of SeaHawk are business process integration, information sharing and collaboration.

“Before SeaHawk it wasn’t uncommon for the different agencies with jurisdiction in the port to duplicate their efforts, said CAPT Michael McAllistar, Coast Guard sector commander and Charleston’s captain of the port. “’My boarding teams would run into Custom’s boarding teams at the bow of a ship.’ Today, boardings are carried out in a more efficient manner that allows the different agencies to make better use of their limited resources.”

The Safe Port Act of 2006 calls “for the creation of similar operational centers at ‘high priority’ ports by October 2009.”

National Defense Magazine identifies the many components comprising the successful architecture for port security:

• Advance Notice of Arrival— provides the captain of the port the information of ships due to arrive, their cargo, and their people 96 hours in advance.
• Automated Identification System (AIS)—“is a beacon that transmits the ship’s identity and bearing.”
• Radar—tracks the ship as it approaches.
• Law Enforcement Dossier—law enforcement—USCG, CBP, and Immigrations and Customs Enforcement (ICE)—compile a dossier that identifies whether any of the crew have criminal records, “whether a ship recently changed ownership or flags, and whether it has been caught with contraband before.”
• Risk Analysis—vessels of interest are color coded and tracked and decisions are made whether to conduct a boarding by USCG and/or CBP or “dispatch CBP canine units that specialize in either drugs or explosive detection.”
• Cameras—“as the ship approaches the port, it is captured by long- and medium-range electro-optical and infrared cameras.”
• Hawkeye System—“combines the data from cameras, radar, and AIS into a common operating picture [COP]. If the ship suddenly veers off course that would raise a red flag.
  
• Wall of Knowledge--“like most modern operation centers, all these cameras, sensors, and tracking systems are displayed on a series of monitors spread across a wall”.

According to the article, one of the architectural challenges is standardizing the technologies and business processes for the various ports, given the challenge that “each port is different” in terms of geography and law enforcement risks (for example, some ports, like Charleston, emphasize port security while others, like in Florida, have a higher risk factors for drugs and illegal immigration). SeaHawk has been successful in this standardization with an 85% solution—“the information software portal has already been adopted by the Coast Guard’s captains of the ports.”

In the future, we can all look forward to seeing SeaHawk rolled out to other major ports, enhancing the security of our nation.

Port Security and Enterprise Architecture

Lessons from Mainframes and Enterprise Architecture

As many organizations have transitioned from a mainframe computing to a more distributed platform, they have become more decentralized and in many cases more lax in terms of managing changes, utilization rates, assuring availability, and standardization.

However, management best practices from the mainframe environment are now being applied to distributed computing,

DM Review, 21 March 2002, reports that “people from the two previously separate cultures—mainframe and distributed [systems]—are coming together to architect, develop, and manage the resulting unified infrastructure.”

1. Virtualization—“Developers of distributed applications can learn from the approach mainframe developers use to build applications that operate effectively in virtualized environments…[such that] operating systems and applications bounce from one server to another as workload change” i.e. effective load balancing. This improves on distributed applications that “have traditionally been designed to run on dedicated servers” resulting in data centers with thousands of servers running at low utilizations rates, consuming lots of power, and having generally low return on investment.
2. Clustering—“A computer cluster is a group of loosely coupled computers that work together closely so that in many respects they can be viewed as though they are a single computer [like a mainframe]…Clusters are usually deployed to improve performance and/or availability over that provided by a single computer, while typically being much more cost-effective than single computers of comparable speed or availability” (Wikipedia) The strategy here is to “reduce the number of servers you need with virtualization, while providing scaling and redundancy with clustering.”
3. Standardization—Distributed computing has traditionally been known for freedom of choice marked by “diversity of hardware, operating platforms, application programming languages, databases, and packaged applications—and an IT infrastructure that is complex to manage and maintain. It takes multiple skill sets to manage and support the diverse application stack…standardization can help you get a handle on [this].

Thus, while we evolve the IT architecture from mainframe to distributed computing, the change in architecture are not so much revolutionary as it is evolutionary. The lessons of mainframe computing that protected our data, ensured efficient utilization and redundancy, and made for a cost-effective IT infrastructure do not have to be lost in a distributed environment. In fact, as architects, we need to ensure the best of both worlds.

Lessons from Mainframes and Enterprise Architecture

Simplification and Enterprise Architecture

Enterprise architecture seeks to simplify organizational complexity through both business processes reengineering and technology enablement. Technology itself is simplified through standardization, consolidation, interoperability, integration, modernization, and component reuse.

Harvard Business Review, December 2007, reports on simplifying the enterprise.

“Large organizations are by nature complex, but over the years circumstances have conspired to add layer upon layer of complexity to how businesses are structured and managed. Well-intentioned responses to new business challenges—globalization, emerging technologies, and regulations…--have left us with companies that are increasingly ungovernable, unwieldy, and underperforming. In many more energy is devoted to navigating the labyrinth than to achieving results.”

Having worked for a few large organizations myself, I can “feel the pain.” Getting up to 8 levels of signature approval on routine management matters is just one such pain point.

What causes complexity?

“Complexity is the cumulative byproduct or organizational changes, big and small that over the years weave complications (often invisibly) into the ways that work is done.”

What is sort of comical here is that the many change management and quality processes that are put in place or attempted may actually do more harm than good, by making changes at the fringes—rather than true simplification and process reengineering at the core of the enterprise.

Here is a checklist for cutting complexity out of your organization:

• “Make simplification a goal, not a virtue—include simplicity…[in] the organization’s strategy; set targets for reducing complexity; create performance incentives that reward simplicity.
• Simplify organizational structure—reduce levels and layers…consolidate similar functions.
• Prune and simplify products and services—employ product portfolio strategy; eliminate, phase out, or sell low-value products; counter feature creep.
• Discipline business and governance processes—create well-defined decision structures (councils and committees); streamline operating processes (planning, budgeting, and so on).
• Simplify personal patterns—counter communication overload; manage meeting time; facilitate collaboration across organizational boundaries.”

Leading enterprise architecture and IT governance for a number of enterprises has shown me that these initiatives must be focused on the end-user and on simplifying process and improving results, rather than creating more unnecessary complexity. The chief architect needs to carefully balance the need for meaningful planning, helpful reviews, and solid documentation and an information repository with simplifying, streamlining, consolidating, reengineering, and facilitating an agile, nimble, and innovative culture.

Simplification and Enterprise Architecture

Microsoft and Enterprise Architecture

Microsoft—with 79,000 employees in 102 countries and global annual revenue of $51.12 billion as of 2007—is the company every consumer loves and hates.

On one hand, Microsoft’s products have transformed the way we use the computer (yeah, I know Apple got there first, but it’s the Microsoft products that we actually use day-to-day). Everything from the Microsoft operating system, office suite, web browser, media player, and so on has made computers understandable, and useable by millions, if not billions of people around the world. The positive impact (excluding the security flaws and pricing) has drastically made our lives better!

On the other hand, Microsoft is a “near-monopoly” with estimated 90%+ market share for Office and Windows O/S. Near-monopolies, like Microsoft are feared to stifle competition, reduce innovation and consumer choice, and drive up prices.

Microsoft has been convicted by the European Commission of having “improperly bundled a media player with its Windows operating system and denied competitors information needed to make their computers work with Microsoft software…fines and penalties could reach…$2.77 billion. “EU officials praised the decision…for protecting consumers.” While “Microsoft backers said, the ruling will stifle innovation by making it tougher to design products with new features.” Additionally, “the EU is reviewing complaints about Microsoft’s Office Software and concerns over how Microsoft bundled encryption and other features in its new Vista operating system.” (Wall Street Journal, 18 September 2007)

From a User-centric EA perspective, there is a similar love-hate relationship with Microsoft. As architects, we believe and preach standardization, consolidation, interoperability, and integration—all things that Microsoft’s array of products help us achieve ‘relatively’ easily (imagine, if instead of an integrated Office Suite, as well as mail, calendar, task list, and underlying operating system, we had to use an array of non-integrated products-yikes!). However, also as architects, we look to be able acquire innovative technology solutions for our organizations that will help us achieve superior mission performance, and to acquire products at prices that produce the best value for the enterprise—to achieve that we need a marketplace based on healthy competition that drives innovation and price competition.

So we love and need Microsoft, but we fear and loathe the ramifications of such market dominance.

Microsoft and Enterprise Architecture