Smarter Enterprise

In developing customer-facing applications for our clients, we often help have the opportunity to collaborate with them about more than technology.  Many of our clients want “a more positive customer experience”, but many of them are fundamentally unaware about the motivations behind their corporate image.  Some people address this through the development of an overall message platform, but an approach that really resonates with potential customers is connecting on the “why”.

For those of you who have not had an opportunity to hear people like Simon Sinek speak to “the golden circle”, then I strongly suggest you take a couple of minutes and listen to him on speak around the why within marketing.

Driving customer relationships from the “why” instead of the “what” facilitates connecting with customers and potential customers at an emotional level.  The ideal scenario would be to have your customers make an emotional decision to connect with your business and a logical decision to possibly purchase from your competitors.

While we are not a marketing company, it’s our experience that first starting with the basics of the corporate strategy, the “why”, enables the customer-facing application to be more about the experience.

It’s all about the why for a company … what’s yours?

General rambling thoughts…

Engaging a running project provides an entirely different set of challenges for the Architect.  Typically, at this point of the engagement, the project is at some crucial point in its life-cycle (why else are you there?).  You are brought in to the picture to either holistically fix the project or provide fire-fighting within a task force mode.  In my experience, the latter is typically the mode of operation.   I assert that the political and organizational aspects of these engagements are on an order of magnitude more difficult to address and fix than that of any technical aspect of the project.  One must delicately traverse through the previous decisions and patterns- understanding that at anytime you may step on a landmine (be careful of flying bodies)… So, to this end while high aptitude and skill-sets are required, equally, if not more important are the Architects political, negotiation, and influencing skills.

…

With the rapid maturing of the overall manufacturing systems within Photovoltaic (PV) manufacturing, businesses need to understand how to achieve the most value within IT investments.  What systems can be deployed to ensure the greatest overall return on investment and enable the highest levels of operational efficiency?  In order to exceed the current and future demands of manufacturing customers, the seamless integration of a flexible and well performing manufacturing execution system (MES) most enables overall cost reduction and business agility.

In an attempt to ensure a common baseline, it is important to quickly address a couple concepts and assertions that help guide the rest of the discussion.

Alignment on Manufacturing Execution Systems Definition

The Manufacturing Enterprise Solutions Association (MESA) defines manufacturing execution systems as:

“A Manufacturing Execution System (MES) is a dynamic information system that drives effective execution of manufacturing operations. Using current and accurate data, MES guides, triggers, and reports on plant activities as events occur…from point of order release into manufacturing to point of product delivery into finished goods.”

While the software products categorized as manufacturing execution systems may vary somewhat, the suite of functions that integrate for a factory wide view may also come from the MESA original MES model. In order to enable manufacturing efficiency, companies will need some or all of the following eleven functions:

• Product Tracking & Genealogy
• Resource Allocation & Status
• Process Management
• Dispatching Production Units
• Performance Analysis
• Quality Management
• Labor Management
• Maintenance Management
• Operations/Detailed Scheduling
• Data Collection/Acquisition
• Document Control

Leverage Experience and Lessons Learnt

Approximately a quarter of a millennia ago, Edmund Burke talked about the absolute necessity of understanding history in order to ensure future learning’s don’t repeat the mistakes of the past. Simply put, the PV industry does not have the luxury of not leveraging past learning from other discrete manufacturing sectors.  From semiconductor to continuous manufacturing segments, there are multiple standards, application integration patterns and domain experience that can be leveraged.  These standards, patterns and experience will enable PV manufacturing to rapidly mature the solutions in alignment of the expanding solar manufacturing base.

Understanding and Incorporating Standards

By now, several norms, recommendations and specifications have been developed, that imply fairly different functionality to be part of the overall manufacturing systems environment.  Some of the standards and bodies that should be leveraged are:
Norms & Guidelines:

• ISA S88, ISA S95
• IEC 61512, IEC 62264
• VDI 5600
• FDA 21 CFR Part 11
• Namur NE33 & NA 94

Recommendations:

• MESA
• VDA
• VDMA
• ZVEI

Specifications:

• SEMATECH CIM Framework Specification 2.0
• SEMI E81-0699 Provisional Specification for CIM Framework Domain Architecture

Cost Reduction Enabling Success

In order to ultimately achieve grid parity, overall cost reduction is the key-enabling factory within Photovoltaic business. Already today, mayor cell and module manufacturers know how to achieve cutting costs of about 40%-50% during the next 3 to 4 years. Anton Milner of Q-Cells stated in spring 2008 for the “Renewable Energy Focus” how this halving could be achieved.

50% of the cost reduction potential lies in continuous technology development, 25% in the law of mass production and another 25% in the conventional progress of productivity.

Mass production, caused by the continuously growing demand in solar technology, means highly automated production lines where key figures (KPIs) like throughput are contradictory to such as yield (efficiency/utilization vs. quality). Therefore, manufacturers use production control systems, specifically Manufacturing Execution Systems, to control and manage their high volume production.

Three more factors that will evolve in the future will increase the requirements for a highly flexible and well performing manufacturing execution system:
1.    Worldwide increasing manufacturing capacities have lead to an oversupply of solar cells in 2009. To diversify in such a market, high quality, i.e. to meet the requirements of long time warranty, and production efficiency above 80% will be mandatory.
2.    In contrast to the earlier common approach of simply “duplicating” low volume production lines, nowadays, manufacturers build Gigawatt factories to reach scaling effects for example regarding facilities. This also leads to more complex requirements regarding MES.
3.    Today, manufacturers try more and more to cover several parts of the PV supply chain and to manufacture more diverse products in one and the same production line (increased product mix). This dramatically increases the requirements for logistics and supply chain demands, which also have to be covered by a MES.

A Path Towards Success

In order to ensure the path towards successfully implementing manufacturing solutions within the PV manufacturing segment, it is critical to first understand the keys to success for the overall implementation.  Some critical keys to success are (not inclusive):

• Overall Reduction of Time to Ramp
• Enable Rapid Learning Cycles
• Focus on Superior Automation (collection & control)
• Integration of “Best of Breed” Components
• Design for Higher Overall “System” Availability

Each of these keys enable companies to simply focus on manufacturing and allows the systems to be a positive factor behind time to market and operational efficiency.  Neglecting and one of the factors begets a negative influence of the manufacturing systems, which dramatically restrict the business strategy and initiatives.

Articulating the Business Requirements

As with any mission critical activity, understanding, documenting and then communicating the requirements for the future state manufacturing systems is the first steps towards achieving implementation success.

Within many projects that don’t realize their initial objective, it is common that there was not enough initial emphasis within the requirements engineering phase and/or the requirements were not well communicated and agreed by all of the stakeholders. Transparency and formal user validation is a key element to any requirements engineering activity.  The communication and alignment of the requirements as well as the overall change management process is key to the overall implementation success.

One proven approach to rapidly articulating a common set of business requirements is leveraging an existing reference model or using subject matter experts to quickly generate the initial version of the overall requirements and use cases.  Using this initial activity as the baseline, then allows business customers to have a valid reference point, which can be modified, reworked or extended.  Such an approach has proven time and again to be the most expedient method towards the realization of the true business requirements.   Independent of the approach; documentation, communication and alignment on the requirements is a critical element of implementation success.

Creation of the Manufacturing Systems Blueprint

Once the requirements are well understood within the organization, the next step is to initially develop the overall manufacturing systems architecture.  The manufacturing systems blueprint is the most effective framework to ensure:
1.    alignment of the business strategy to the systems and manufacturing IT initiatives
2.    assurance of the overall requirements through the business and manufacturing processes
3.    enables repeatability and extensibility of the entire solution
4.    documents and provides governance of the principles and processes

From the Open Group (TOGAF) to the Zachman Framwork, there are several methods that can be implemented for the realization of the overall manufacturing systems blueprint.  Each of the methodologies cover similar concepts, but simply enable a slightly different view and approach to technical and business architecture.  The keys to implementation success are simple:  use one approach and ensure active development of the framework and continued improvement of the processes.

Manufacturing Systems Evaluation and Selection

With a key understanding of the requirements and the initial concepts within the manufacturing systems blueprint, it is now time to start the overall manufacturing systems evaluation and selection. There exist a few key factors in ensuring the success of the overall MES evaluation and selection process:
1.    Use the documented requirements and systems blueprint as a basis.
2.    Leverage the results from completed previous evaluation processes.
3.    Guide the selection by the overall manufacturing system principles

Each of these success factors are commonly neglected within the evaluation processes, but #1 and #3 are the two most critical to ensure.  If a business does not truly understand its fundamental requirements, then it’s simply not possible to ensure the solution fit to the overall manufacturing systems objectives.  Additionally, unless your parent company also provides MES solutions, then BUY, don’t build.   Oversimplifying and underestimating the scope of work to develop an independent execution system is one of the most common mistakes within manufacturing businesses.

Manufacturing Systems – Implementation to Optimization

With the requirements documented, blueprint established and the selection of the primary manufacturing systems components; now you can focus on implementation to optimization.  It is critical to ensure that the overall systems are in place in alignment with the primary phases of the manufacturing facility itself.  Again, leveraging subject matter expertise within this space ensures the key business enabling factors that were previously discussed and enables the overall manufacturing systems to be valued added and cost effective for the business.

I have been anxiously awaiting the SATURN (SEI Architecture Technology User Network) 2009 conference – and it is now upon us.  With the current economic situation, I anticipate this years conference to be a bit smaller than previous years.  Looking at the keynote speaker and presentation list, I am confident that the conference will meet most of my objectives.

The keynote this year is titled ‘Architecture is Architecture’,  and is given by John Zachman.  I’m anticipating that a good portion of his speech will be around the Zachman framework, however I’m looking forward to his insights into:

• what enterprise architecture is NOT
• what enterprise architecture IS
• Enterprise Architecture is not arbitrary…and not negotiable.
• managing the enterprise “knowledge base”
• Enterprise architecture and system implementation are two different things.

A few other presentations on the menu are: (It is my intention to provide a brief overview of each of the presentations – depending on time….)

Lessons Learned from Architecture Reviews
Rebecca Wirfs-Brock, Wirfs-Brock Associates, USA

Bridging Systems and Software Architecture
Anne-Marie Buibish, James Lewis, Elizabeth Penisten, Amy Lange,
and Caleb Conley, Raytheon, USA

A Simple and Flexible Specification for an Enterprise Architecture Practice
David Cuyler, Sandia National Laboratories, USA

Limits to the Use of the Zachman Framework in Developing and Evolving Architectures for Complex Systems of Systems
Suzanne Garcia and Philip Boxer, Software Engineering Institute, USA

Architecting Your Organization
Kenneth Kunkel, IBM, USA

Career Track for Architects in IT Service Provider Organizations
Shankar Kambhampaty, Satyam Computer Services Limited, India

The Role and Development of an Enterprise Architect:
A Devil’s Advocate’s Perspective
Robert Ellinger, Northrop Grumman Corporation, USA

Integrating Usability Supporting Architectural Patterns in a
Product Line System’s Architecture
Pia Stoll, ABB, Sweden
Len Bass, Software Engineering Institute, USA
Elspeth Golden, Carnegie Mellon University
Bonnie John, Carnegie Mellon University

Improving the Definition of Quality Attribute Scenarios by Using Requirements Patterns
Aldo Dagnino, ABB, USA

Architecting for Highly Available, Scalable, and Reliable Mission-Critical Applications
Diego Dagum, Microsoft, USA

Dealing with Quality Attribute Requirements as the Hero, Not the Witch
Andre Gous, Precision Quality Software, USA

Experience with the Architecture Improvement Workshop
Lawrence Jones, Software Engineering Institute, USA
Rick Kazman, Software Engineering Institute, USA

Bottom-Up Software Product Line Design: A Case Study Emphasizing the Need for Stakeholder Commitment
Roland Weiss, Jens Doppelhamer, and Heiko Koziolek
ABB, Germany

Architecture Governance and Rules Enforcement Using AOP and SonarJ—A Case Study
Srini Penchikala, InfoQ, USA

I am looking forward to the discussions blending both theory and practical knowledge and experiences.

… to be continued …  (off to the aiport)

Overall data stratification is about data residing at different layers within the architecture.  The purpose, scope, nature, content, granularity and retention time are attributed to the specific layer of the stratification.

Figure A High Level Data Stratification Architecture

The origin of data is either based on automated data collected from the equipment or manually by a human via shop floor interfaces.  The data at this layer of the stratification is the most granular and represents the current state of information within a specific function space.  Typically, this data is first either persistently stored on the processing equipment (for later storage within an operational database) or immediately fed into an operational database.  As data moves up the stratification, the data is aggregated and stored into common schemas for greater levels of correlation with other data.

Typically, common data stratification layers are:

• Equipment (Local Storage)
• Operational Databases
• Operational Shadows
• Operational Data Store
• Data Warehouse
• Data Marts

By implementing a true operational reporting layer, the operational systems can be better tuned in drive better execution systems performance, common reporting tools can be deployed at multiple levels within the stratification, and the critical factory data is retained to ensure that the right level of information is available.

Equipment (Local Storage)
Equipment local storage is simply that, local (or possibly networked) drives that are available to the equipment.  Obviously, this is the lowest level of raw data, logs, and information about the equipment.  Typically within previously generations of factory systems (with limited FDC integration, RS232 limited communication, less sophisticated equipment integration) this data was accessed directly off the equipment for uncontrolled usage by the equipment and process engineering teams.  Today, with the more advances features of the shop floor architecture, access to this data off the tool should be highly discouraged or possibly even restricted.

The key characteristics of the operational databases are as follows:
Usage: Internal tool usage and reporting
Data Retention:  Dependant on the configuration of the specific tool and equipment engineer administration.
Aggregation: Typically only raw or derived data from the tool software
Access:  Should be restricted to the equipment automation

While it is common for data (processing data and instructions) to be fed down from executions systems to the tool, for the purposes of the overall data stratification, then information flow should be thought to flow from the tools upwards into the operational databases.

The data from the equipment local storage is not typically backed up for purposes of being able to later fetch the data for some use.  However, it is common for this level of data to be backed up, though this is not usually done with a common methodology.

Within most published information about manufacturing data stratification, the equipment local storage is not typically included.  However, it is included in this paper to show the data source origin and specifically comment on a principle to not use data directly off the tool, but rather have manufacturing systems access this and persistently store it within another layer.

Operational Databases
Operational databases contain data that is either entered via automated or manual interfaces.  The content of the data should be current information only and is used for both execution tracking and control.  Operational systems are typically purchased off the shelf from commercial providers so a common characteristic is for them to have their own proprietary schemas, which are optimized for the application use and not usually easily correlated between themselves.  Access to the data within the operational systems should be highly restricted to applications and clients; reporting should never be done within this layer of the stratification.

Obviously, the manufacturing execution system (MES) is the most common operational database and a key part of the overall data stratification.

The key characteristics of the operational databases are as follows.
Usage: WIP Tracking, Equipment Tracking, Engineering Data Collection, etc.
Data Retention:  Typically only current WIP within the factory
Aggregation: Raw data, only aggregation is for application efficiency
Access:  [Real Time] Application Level, user interface via controlled services

Information commonly flows between the various operational systems for tracking and execution control purposes, but again the information flow from the data stratification perspective should be thought to flow up towards the operational data stores.  Typically, only object and historical data is fed up into the operational data store; however there is usually a considerable amount of information that only resides on the operational which is only specific to the application usage at the operational level.

The data of the operational database is ideally purged and not archived.  It is a best practice to not use this level of the stratification for de-archiving information, unless that information physically represents objects that have re-entered the factory.

Operational Shadows
While not really part of the overall data stratification, operational shadows are at least worth mentioning within it’s context as they are critical for the availability of the operational systems and depending on the replication methodology implemented, it is sometimes possible to be leveraged.

The key characteristics of the operational shadows is as follows:
Usage:   Operational Systems High Availability and Partial Disaster Recovery
Data Retention:  Same as the operational system it is shadowing
Aggregation:  Same as the operational system it is shadowing
Access:  When online synchronization is on, access should be restricted.  However, depending on the shadow methodology, a good practice is to take operational statistics and metrics from the shadow database weekly if it is able to not be online for a specified period.

The information flow to the operational shadow is intended strictly for the higher availability of the operational systems.  There is really not a common backup methodology within this level as typically it is the backup for the operational systems.

Operational Data Store
Operational data stores contain the first level of common, correlated data within the stratification.  A critical aspect of the operational data store is a well-architected common schema that can be loaded from the various operational databases.  This level of the stratification should be leveraged as both the primary reporting information store for the factory as well as data feed for various data marts, as needed for specific needs like engineering data analysis.  Access to this level is typically controlled through production reporting tools and is based on well-designed and optimized data access.  Data from within an operational data store is typically from only one facility or factory, but the enterprise should share one common schema (even if there are different operational systems that feed it) to ensure that data can be easily shared across the enterprise at the next level of the data stratification.

The key characteristics of the operational database store is as follows:
Usage:   Production reporting, part traceability & tracking
Data Retention:  Typically 12-18 months
Aggregation:  Some Raw data tending to more aggregation to make more efficient operational reporting
Access:  [Near Real Time – minutes delayed] Web-based reporting, reporting tools (with already optimized data access) and applications

Information flows up the stratification to the enterprise data warehouses, but also typically flows through the operational data store to feed data marts.  It is a very good practice to ensure that data flows through the operational data stores to the data marts instead of direct data feeds to the data marts so that information can be commonly controlled though one channel.

The operational data store should be the first level of the data stratification implemented as it has the most immediate benefit to the enterprise.

The data of the operational data store is backed up typically using common database archiving methodologies and should be implemented in such a way that the data can later be retrieved to meet manufacturing use cases (for offline data retrieval) as well as availability purposes.  Typically, corporations have legal requirements for the archival and retention.  These requirements should be designed in to be satisfied at this level of the data stratification as it typically has enough of the raw data in order to meet these requirements, but does not burden the operational systems with having to meet this requirement.

Data Warehouse
The data warehouse contains information for the entire enterprise and consists of the highest level of aggregated data.  The data retention of the data warehouse is the longest of any level of the data stratification.  The use of this information is typically for operational and manufacturing performance metrics based on common reporting tools.  Access to this level should not be ad-hoc due to the very large levels of history that is stored within the data warehouse.  The schema of this database should be common across the enterprise, which is often achieved by having only one data warehouse.  This common schema should be based on that of the operational data store, but typically can not be the same as much of the data is aggregated and filtered to meet the specific needs of enterprise metrics.

The key characteristics of the data warehouse is as follows:
Usage: Cross-Factory Reporting, Metrics, and Information Sharing
Data Retention:  Typically only current WIP within the factory.
Aggregation:  Limited raw data, mostly aggregated data
Access:  [Delayed – typically an hour old] Corporate reporting tools and applications.

While ultimately this level is very beneficial to the enterprise, it is typically the last level that is implemented within the overall stratification as the purpose can be substituted through data channels from the operational data store.  In addition, since the data retention of the operational data store is typically around or greater than eighteen (18) months, the urgency of implementation is less than other levels.

The data within the data warehouse is commonly backed up using standard database methodologies and it is not a common practice to move this data or bring information that has been archived back into the data warehouse.

Data Marts
The data marts are usually designed to cover specific part traceability, financial or engineering data analysis purposes.  The schemas of these data marts are not typically common, but suited to the specific needs of the data mart.  The data retention should be optimized for the use of the data mart, but is typically greater than a year.  It is common that data marts only contain data for specific uses along with the critical manufacturing contexts (lots, equipment, etc.).

The key characteristics of data marts are as follows:
Usage: Specific to data mart type (engineering analysis, part tracking, etc.)
Data Retention:  Specific to data mart
Aggregation:  Specific to data mart
Access:  [Offline] Specific to the data mart, capabilities to export own data for further analysis

The information flow of the data mart should come from the operational data store to ensure a common data channel to each of the specific data marts and ensure that they contain common data.  It is not uncommon to have some data (typically aggregated or summarized) fed back to the operational data store.

The data within the data marts is backup up using either application specific or common database procedures.  They typically do not share common backup methodologies between each of the specific data marts.

With the explosion of social media, it seems that a corporation is simply not “hip” unless they have an active blog site.  Whether it’s a tweet within a conference or a simple status update in Facebook, we are all immersed with many new social media channels at our disposal.  I am often at a conference or a meeting where the speaker’s remarks include “read my blog”, which make me simply wonder, why?  Is there something in the blog that will add value to my life or my business?  Are the Tweeter sessions within a conference actually productive or, at times, are they much to focused on trivial elements and observations?  Do I get more value out of the speaker’s tie harassment from dmb1991 or from paying better attention to the keynote that I came to see in the first place?

In a slow migration from rant to added value, I would love to hear about case studies and real world examples of how social media enriched your life your business.  Please comments and link to sites that you feel are “social media enabled”.

Okay, so welcome to our blog and I hope that you sign up and become an active, value added participant.