IT Managers responsible for deploying PLM, I feel for you. I really do.

Deploying CAD software? Fairly straightforward. The devil’s in the installation and maintenance details. It is, however, a relatively well-traveled road. You know what issues are likely to crop up.

Deploying CAE software? Maybe a little complicated as the myriad of pre-processors, solvers and post-processors can multiply. But again, the problems lie in consistently installing the software.

Deploying PLM or PDM? Heh. That’s literally a whole different class of software. Many things can go horribly wrong along the way to a go-live date. If you’re leading the deployment of such a system, be ready. There will be surprises along the way. What surprises? Well, let’s discuss.

The “Legacy Data” Pitfall of PLM

Now, if you’ve followed some of my posts in the past, you’ve seen that I’ve written about deploying PLM. Most recently, I’ve gotten into a good debate with Jos Voskuil and Oleg Shilovitsky on the direction of PLM. And while I disagree with some of the issues around PLM, I do agree with Oleg on one point at least. Way back in 2007, Oleg published a post titled the 3 Main Factors in PLM Adoption. And here’s the point with which I agree.

In order to run your manufacturing environment, you need to have “your data” in the system. Without this, you are not actually running your manufacturing with PLM. To get legacy data in the system is a very painful task, in my view. I have almost never seen this happen easily. There is, almost every time, a set of complicated steps of exporting and importing data. As there is no standard data, we come back partially to factor #1 (customization) again.

Here, Oleg’s talking about legacy data and its relevance to a PLM deployment. Why exactly is this important? Well, let’s walk through an example.

One Workday Morning,

…  you’re getting close to that PLM go-live date. All your ducks are in a row. The users have been notified of the roll out and are prepared. Your executives have tracked your progress all along the way. You’ve kept to the milestones and managed their expectations accordingly. Everything is on track.

Your task today is to migrate some legacy data from a few old systems into the PLM system. You set out on your task.

You are ready to move some CAD data from an old outdated PDM system. You set up the batch process and move on to another task. Checking back before lunch, you start to look at the data in the PLM system. To your horror, you find that key parameters are missing values. You check the original data and, lo and behold, much of it is scrambled. With thousands of entries, you’re staring at a huge delay in the PLM deployment.

Right. In. The. Face.

Now, of course, it can be fixed. But it will take time. Lots of it. The bigger issue is expectations.

You have to go the executives and announce the delay. Suddenly the word “painful” seems woefully underpowered. You have to go the users and let them know new projects won’t switch systems just yet. No pats on the back for that one.

Mitigate the Risk

OK. So what’s the alternative? There are some new data analysis tools that can check the health of legacy data before you reach that “sink or swim” moment. These tools let you check the completeness of the metadata for CAD files and other data. It can check to ensure interconnections between files exist and can be maintained during the migration.

Let’s be frank. This kind of tool isn’t the flashiest in the world. C’mon, you’re looking at data. But in all seriousness, when you’re on a schedule, and what PLM deployment isn’t on a schedule, and you’ve set expectations, and who would be deploying such a system without doing so, being thorough is important. And that’s why technology like this is important.

Summary and Conclusion

Alright, let’s recap.

• There are a few issues that can trip up a PLM deployment. Legacy data is one of them. And they can cause delays in the PLM deployment schedule.
• There certainly are implications of a delay in the deployment of PLM for the organization, but there are very personal implications for the IT manager that’s responsible. Having to painfully reset expectations of executives and users falls into that category.
• There are some data analysis tools that can uncover issues with legacy data. They aren’t the flashiest ones, but they address the issues that can cause delays in PLM deployments.

Well, I’ve said my piece. What’s your take? Any stories about legacy data and PLM deployments? Is this an overstated or understated problem? Sound off and let us know what you think.

Take care. Talk soon. And thanks for reading.

The post Mitigating the Legacy Data Risk to PLM Deployments appeared first on I-Cubed.

One of Adobe Experience Manager‘s (formerly Adobe CQ5) primary pillars of application development is Apache Felix, an implementation of the OSGi specification. OSGi provides developers with a way to create applications at a modular level, allowing the development and management of individual components that work together to form that larger puzzle as an adaptive and dynamic system. Let’s take a look at the ways this crucial piece of the CQ5 technology stack assists developers in the creation of applications rich with functionality.

Components

OSGi provides a registry for a service-oriented and component-based environment, and allows a developer to design his or her implementation in small manageable chunks by placing units of code inside of bundles (which are essentially .jar files). These contain information that describes the functional units, such as version, the packages it imports or requires, and the packages it exports. This gives you a reusable component that can be “plugged in” with other components that can make use of its functionality.

For the bundles to be able to interact, the OSGi specification defines the service layer. This describes a registry for services which may be shared. Components hide their implementations from other components while communicating through services and objects shared between components. Developing in this way provides huge advantages in that you can freely change the implementation of the classes in your bundle, and still provide the same functionality for other bundles to use. Overall, complexity is reduced and re-use is increased.

Managing the Functional Pieces

Each bundle in your system goes through a lifecycle consisting of various states, including starting, stopping and active, as well as resolved, installed, and uninstalled. What’s so great about having these states? Alone, they aren’t actually doing anything too exciting (aside from allowing for the hooking of a component’s logic into the lifecycle process of another bundle). What is exciting is the fact that these states can occur at any point while your application is running—meaning you can swap out one of your functional pieces without ever having to restart the entire system. This equates to a development environment with virtually no deployment downtime, as well as significantly easier debugging.

Whether you’ve deployed a simple bug fix, or implemented a brand new feature, the entire process can be completely transparent to your end-users, accelerating the time to delivery. CQ5 with Apache Felix also provides  easy-to-use visual administration for managing the states and configurations of your bundles with nothing but a few clicks from your CQ5 system console.

Performance

There are, of course, many cases in which a developer is completely willing to sacrifice such usability and management for the sake of performance. With CQ5 and Apache Felix, however, you don’t have to make this sacrifice. OSGi’s speed and minimal footprint makes for applications that are not only manageable for your developers, but fast for your users.

Community

OSGi is a successful and widely accepted platform of modular Java development. Documentation and resources for using it are no more than a few clicks away. Apache Felix itself is only one of many implementations of the specification, any of which can be used in CQ5. Such acceptance gives new adopters of the technology a great head start by being able to quickly learn how to use it, while also developing fully featured and easily manageable applications.

The post OSGi with Adobe Experience Manager (CQ5) appeared first on I-Cubed.

“An important goal at I-Cubed is pursuing greater sustainability, and JouleBug equipped us with the practical knowledge necessary to achieve this,” said current President and CEO of I-Cubed, Donald A. Thompson, Jr. “Knowing how to save energy enables us to decrease costs and reduce our impact on the environment. As a whole, our company learned to be more responsible in our energy decisions.”

The JouleBug app rewards users for choices that contribute to energy sustainability with points and badges: virtual trophies representing real-world savings. Users can also compete with friends via Twitter and Facebook. JouleBug users can also participate in community competitions and earn real prizes. A segment on the competition at I-Cubed aired on local CBS affiliate WRAL on May 3rd, and the video segment can also be found on the WRAL website.

“JouleBug makes saving energy fun and competitive. Users can cut their energy costs by more than $200 a year, and that really adds up when entire companies or communities compete in JouleBug Challenges,” said Grant Williard, founder and president of JouleBug,

Williard developed the app in partnership with a sustainability engineer and computer scientists from NC State. Released in late 2012, the app has already obtained the distinction of being named an i2i (“Innovation to Inspiration”) awardee at South by Southwest Eco 2012. In addition to I-Cubed, the City of Raleigh, NC State University, Wake Tech Community College, and the City of Santa Fe, New Mexico, have also engaged in JouleBug Challenges.

To learn more about JouleBug and download the app, visit http://www.joulebug.com/

About I-Cubed

Since 1984, I-Cubed has solved complex technical problems for enterprise customers. The company is a leading solutions provider in the areas of product lifecycle management (PLM) consulting, web experience management and managed services. Strategic relationships with industry leaders, such as PTC and Adobe, allow I-Cubed to deliver high-quality solutions with a global reach. For more information about I-Cubed, please visit www.i-cubed.com.

About JouleBug

JouleBug is a playful mobile app that encourages users to improve their sustainability habits at home, work, and play. By competing with their Facebook and Twitter friends to earn badges and pins, users can lower energy bills, reduce waste, and make a big impact on the planet. Created by a team of developers, designers, sustainability engineers and writers, JouleBug is led by Grant Williard and is headquartered in Raleigh, NC. Learn more and download the app at www.joulebug.com.

###

Contact:

Janice Yucel
I-Cubed
(919) 755-5300
janice.yucel@i-cubed.com
http://www.i-cubed.com

The post I-Cubed Completes JouleBug Energy Sustainability Challenge appeared first on I-Cubed.

How do your engineers know which parts to use?

As an Original Equipment Manufacturer, you may be working with multiple manufacturers and vendors. Often times, you have several suppliers for the same parts. This information is either stored in a third party system, in Windchill attributes or in physical forms. With SUMA, Approved manufacturer and vendor lists organize your manufacturer part to your OEM part relationship. With AMLs, you also rank which supplier parts are preferred over others.

Selecting the best parts for the job

With companies becoming more global, you may have factories all over the world. These factories may be making the same assemblies as others. In this case, they will be buying manufacturer parts from the same suppliers.

However, due to distance, regulations, etc., availability may vary by factory and it is important that this difference is reflected in the data. Supplier contexts will allow for many different AMLs to be set for the same part. These contexts can be organized by geography, costs or however would best fit your company’s needs.

There are many factors that can affect a supplier relationship.

A supplier can increase its prices, move a factory overseas, stop selling items or go out of business altogether. In this case, it can be incredibly costly if engineers have to change the status of your manufacturing or vendor parts. SUMA offers sourcing rules that will allow users to change the status of all a supplier’s parts, with the freedom to apply them per sourcing context. These rules also allow for a supplier’s parts to be created with their status automatically set.

Procuring the part you need can be tricky

Requests for parts are often handled through email and manually filled out forms, which might not contain all of the required data. Procurement will then search through Windchill for all the related parts to evaluate and make a decision. Unless performed manually, there is nothing tracking if this part has been requested or noting procurement’s decision.

Using Part Requests, added with SUMA, the engineer would be able to perform a few clicks to send a task to the procurement engineer, showing up in his assignments list, including all relevant parts and desired part requirements. The PE can perform his evaluation and email the part request off to the supplier. This whole process is tracked and the engineer receives a part that fits all of his requirements

The day-to-day troubles of working with supplier data become much more manageable when using Windchill Supplier Management. Approved manufacturer lists provide engineers with a simple list of usable supplier parts. Sourcing contexts and rules make managing part relationships much easier. Part requests make procurement a traceable and repeatable process that can greatly reduce time to acquire. If your company works with numerous suppliers, ask your PLM consultants how SUMA can increase your overall efficiency and help keep costs down.

The post SUMA: Integrating Supply Chain into Windchill appeared first on I-Cubed.

Extraction: the word itself sets the expectation that things may get difficult. “Extraction is to remove or take out by effort or force,” as said by Webster. However, if planned and executed correctly, the definition could be updated as follows: “Remove or take out automatically and efficiently,” as said by I-Cubed.

Extractions are required when one needs to move data from one location to another. The type of data can vary between content and metadata; some common types in PLM (product lifecycle management) extractions are:

• CAD Files
• Bills of Materials (BOMs)
• Part Attributes
• Change Objects (ECRs, ECNs)
• Usage and Dependency Links
• Usernames

In some cases, both content and metadata reside in the same source; however, in others you may find a mixture between multiple sources. For example, the CAD Files may reside in a Product Data Management (PDM) system and the Part Attributes in an Enterprise Resource Planning (ERP) system.

CAD file extractions tend to be the most difficult due to the complexities involving dependencies and relationships required by the authoring tools. This can be elevated somewhat depending on the history requirements. Full history extractions are the most complex, requiring countless configurations, relationships and dependencies for every version of every object. The extraction becomes less complex as historical requirements are removed by only extracting the latest version of each object.

In any case, a very deep understanding of the source data and source system is needed to carry out a proper extraction. As extractions are the foundation of a successful migration, it is important they are done correctly by experts who completely understand the data and environments.

The post Extraction, the First Step in a Successful Migration appeared first on I-Cubed.

As we were just beginning to look into CQ as a technology to pursue, it struck us that our needs for the RPM and the capabilities of CQ coincided rather perfectly. It gives our resources a way to author their own profiles while simultaneously being restricted from editing others using CQ5’s permissions system and user groups.

Any changes that a resource makes can be sent to that resource’s manager for approval; this process is automated using CQ’s built-in workflow system, which will also send out emails to all relevant parties.

The ability to sync with the company’s LDAP system is also quite useful, as it allows any resource that has been entered into the LDAP to login and access the RPM, without passing the burden of managing those systems to the IT department.

We also created a check for first-time logins which automatically creates the resource profile page and readies it for authoring. For these and many other features, CQ was a great choice for the RPM, but the final benefit was unexpected: it provides an amazing training tool for both new developers to learn the basics, as well as keeping the skills of seasoned veterans sharp.

Through the development of new features, the RPM provides us with a way to train our new resources, from the broad strokes of basic CQ development, to the fine tunings that transform a CQ environment from functional to fantastic. They learn the foundations of CQ project architecture, as well as the pitfalls to avoid when building from the ground up. Further, the project has a wealth of software examples for our new hires to study, above and far beyond anything found in any training documents, that allows the resources to examine and learn CQ development best practices. The system can even work as a canvas for senior developers to research and experiment with better CQ development techniques.

The post CQ Best Practices: I-Cubed Resource Profile Manager appeared first on I-Cubed.

In nearly all endeavors there are constraints placed upon us.  Data migrations are no different.  The constraints during a migration can be due to wide range of reasons, including target system restrictions, business rules, and migration tool capabilities.  Each of these constraints can inhibit or even block the migration.  So how do we anticipate the impact of these constraints? Analysis.

Analysis is the investigation of the properties of data, and, in particular, comparing those properties against the requirements and constraints of a migration.

Why is Analysis so important?  Attempting to migrate data that conflicts with the constraints of the process will likely either a) fail, or b) migrate and be unusable after the migration.  If the former occurs, your migration will be incomplete, if the latter occurs, your migration could be a disaster.  Good Analysis provides the insight into the data BEFORE you migrate, allowing you the opportunity to resolve the issues before they create problems.  As many manufacturers will tell you, it is much less expensive to correct a problem during the design stage rather than waiting until manufacturing begins.

What will a good Analysis tell you?  A good Analysis will identify many issues including:

• Attribute values that are incompatible with the business rules
• Information or files that are missing
• Scope of the Transforms required
• Data collisions
• Corrupt data

With this information one can plan for the mitigation of the issues and determine a predictable migration path.  So I no longer use ETLV to describe migrations, but rather ETALV.

The post The ‘A’ in ETLV appeared first on I-Cubed.

When retrieving content from various providers, it is imperative to properly taxonomize this content in a way that is both intuitive and maintainable. This can be achieved quite easily using CQ Tags. While the idea of tagging content is not new to the internet world, CQ5’s implementation of tags provides a more dynamic approach for categorizing content for a website. The flexibility of CQ5’s tagging functionality provides a way to dictate the way content is classified depending on how general or specific the user prefers to structure this organization. For example, we could classify all sports related articles into a ‘Sports’ group, or we can group them into their own respective sports, such as “Basketball”, or both “sports” and “basketball.”

CQ5 tags usually consist of a namespace, container tags, and/or leaf tag. Content can be tagged using all, one, or a combination of each. Looking at it from a top-down approach, namespaces provide a high-level of organization for content , and should only be applied to application-level domains. A couple namespace examples could be“WCM” or “DAM.” Moving down the ladder, container tags are basically subgroups of the namespaces that allows for grouping of content as well.

And last is the leaf node, which is the most granulized level for tagging content. Given the absolute tag ID of ‘dam:sports/basketball/college/mens ’, the namespace would be ‘dam’, which is in reference to the DAM. The container tags would be “sports,” “basketball,” and “college,” and the leaf tag would be “mens.” The absolute tag path would be “/etc/tags/dam/sports/basketball/college/mens.” For developers, the absolute tag path can be used to resolve a resource.

By properly tagging content, we can utilize and extend CQ5’s out-of-the-box list component to consolidate multiple content pages into a centralized list of links to each individual page as seen in the screen shot below.

The list component allows the author to merge content with ease via page searches, tags, querybuilder, and other search mechanisms. The author can apply multiple tags to the search query to create a list with the intended scope of tagged content, and with a little engineering, a list of decorated links to content pages can be created. One of the main benefits of creating a centralized list of content pages is giving the end user easy access to multiple articles that may be hidden within the sea of articles maintained within a website.

In summation, CQ5’s breadth of out-of-the-box functionality makes it easy for users to provide efficient implementation for a multitude of various sites. This is just one example out of many that demonstrates CQ5’s extensibility.

The post More content than you can handle, huh? Let CQ5 ease the pain for you… appeared first on I-Cubed.

Full History

Full history migrations move all occurrences of data.  All released versions, all interim iterations and all pre-release and prototype iterations are included in a full history migration.

There are two requirements of full history migration.  First, the source data must include relationship information for all dependency types.  The data must specify the exact revision, iteration and or occurrence of both the parent and the child of each dependency relationship. Secondly, the resources to perform a full history migration are geometrically greater than the resources required for other migration options. Gathering the data and managing the process of migration requires much more time.  As the size of the migration increases the time required—particularly exception handling—growth can increase exponentially.

Latest Released

Another option is to migrate the latest release of each revision along with the latest work-in-process. This reduces the amount of time and effort from a full history migration and still moves the significant historical data to the target system. The source system must still be able to provide the iteration level information for all dependency relationships, however, the amount of time to prepare, load and validate is much less than a full history migration. For very large migrations this too may be an expensive proposition.

Latest Only

Migrating the latest released and latest work-in-process data is the simplest of the three options. This option brings the data required to move forward with new designs, and is ideal for very large migrations, and migrations where a good document of record exists in another format or the historical data is of low value. A latest only migration requires the least amount of time to migrate.

The post Migration Options – Historical Data appeared first on I-Cubed.

The first principle: quality and usability of the data is paramount. The data we migrate is the lifeblood of our customers.  Their business depends upon having good, usable data and information. As custodians of their data during a migration, we must honor and protect their data and ensure it meets the needs of their business once the migration is completed.

The second principle is to identify problems as early in the process as possible. When migrating data from one system to another, it is inevitable that problems will arise. Some problems are due to differences in the management of data between the source and the target systems. Not all systems manage data in the same manner. Sometimes the processes in use in the old system allowed for inconsistencies that are not acceptable in the target system. In some cases there are new rules put into place for the new system that did not exist in the old system.

The third principle is to load as much data as we can.  Much of the data we load is interdependent on other data. Assemblies modeled in a CAD system depend upon subassemblies and component parts. Without those dependent files the assembly would not be usable.  If revision history is a requirement of the migration, then later versions of a part or assembly depends upon earlier versions of that part or assembly.

The fourth principle, based upon the first principle, is to load data with the same software that will be used after migration, if possible. And if not possible, use a loading tool that closely mimics how the data will be used after migration. One way to ensure data compatibility with the customer’s target toolset is to use those tools to load the data.

The final principle is to validate early, validate often.  Validation is the mechanism one uses to ensure quality (see the first principle). A migration is most often a series of steps. The typical steps include Extract, Transform, Load, and Validate (ETLV).  The data will often times be moved at least two times and the data will often be changed (transformed) at least once. The “validate early, validate often” principle dictates that each time the data is moved or changed, it needs to be validated.  This follows not just the first principle of quality but also the second principle of identifying problems early.

In future entries we will look at each of these principles in more depth. We will look at how they are implemented from a vendor point of view, as well as how a customer can adopt these principles when embarking on a data migration.

The post The I-Cubed Data Migration Philosophy appeared first on I-Cubed.