Anticipation

Now for the future. The last blog began by a glance over the shoulder to the past. This week, the perspective is forward looking.  And a new departure – a European location from which to make a posting. 

I’m in the Mentor Graphics office in Newbury, England and earlier in the week spent some time in the office in Altrincham farther north.  Preparations are in full swing for the release of 2009.1 and whilst I download a few pieces of environment and cannot proceed with a tutorial exercise, I can share a few details of what’s new. But not much in the way of detail, as the official list of what is contained in the release is concealed from the world at large untill public launch date. Here are the details I can reveal. It will be good. There will be additional new things.  Er, that’s about as far as I can go.

As well as the content of the new release I’m getting to know some of the ins and outs of CHS Harness XC styling capabilities a little deeper than I have already experienced. It is impressive. Tomorrow is Capital Analysis day. Analysis models. So the option of a modeling career is possibly open to me – in a sense. Yesterday also included a deep dive into the generative design flow and an exploration of the power of the Composite Wire Synthesis and the Abstract Wire Synthesis processes, CWS/AWS. In the future there will be no lessening of the pace of three letter acronyms. Mentor’s Integrated Electrical Systems Division programmers are devising new ones. 

Good opportunity also to hobnob with the colleagues from various parts of Europe, India and with familiar faces from North America who have also travelled over. Mentor Graphics divides staff into “factory” and “field” – distinguishing between those who are on the production side of the software business and those like myself who have more constant customer contact. Which reminds me, as well as the training and technical updates, there are a few emails from the jolly fine people whose success makes my continued employment happen. So I will go and deal with the half dozen emails which have popped into my inbox in the last half hour.

A lot in Electrical CAD and manufacturing quality hinges on data accuracy and completeness of the library data. From the carrion-crow-like perch of someone supporting design automation software, the immense and patient contribution of the ECAD librarians is often missed.  

A couple of co-inciding recent events brought me to a renewed understanding of the significance of the work librarians do. Those 2 events were a visit to a customer, and  reading a book. The book, I picked up at a church hall used book sale. Quality is Free – the Art of Making Quality Certain. It was first published in paperback in 1980, ISBN 0451624688 by author Philip B. Crosby.

This book has a few things going for it, one of which is it is a Mentor publication – but no relation to Mentor Graphics. The Mentor Books – New American Library, is, or at least was then, a sub-division of McGraw Hill Publishing. For a chance encounter it was interesting reading and a good slice of luck. I think it is out of print now. The domain the book covers is general industrial production and as well as offering  plenty of nuggets of straightforward wisdom like “act now for reward later” Crosby goes into convincing detail about the patience required to achieve quality improvements.

I like that a librarian themed blog post involves a book. Next time you go into a public library be sure to wish the person behind the counter “Many Happy Returns”

Empowering librarians:

A high quality electrical parts library to support wiring designs is achieved first by putting in place the right resources for the right length of time. But a close second is senior management makes the responsibilities of librarians untouchable and uncompromised. Giving librarians the authority and autonomy to manage their domain is highly beneficial. A division of labor has been popular in for profit organizations since mediaeval times. It is a winning formula. Librarians have better expertise and the experience in component data management than harness design engineers for example, who to give them their due are far better and more valuable as designers than the librarians may be. Better quality data in the library is not a finish line to pass and then forget about and go on to the next thing, it is an ongoing commitment.

Comprehensive and complete data.

Imagine there is a missing electrical connector in the library. Is the quality problem of the part not being present solved by the part reference being added? If you think at first blush that this is the end, then consider whether for electrical CAD purposes a basic definition really will suffice. Depends what you mean by a “basic” set of information might be your reply. What to include in the set of basic information then? A majority of engineers may want an accurate cross-reference to who the supplier of the part is additional their own internal part numbering system. You want to know where the part can be sourced from. If that part reference, any part reference contains separation or position significance coding, well that’s got to be accurate too for consumers of the data down the line.

Yes, accuracy makes a tremendous difference:

The CHS system has a lengthy list of off-the-shelf design rule checks which can be supplemented through the extensibility features.

What’s the difference in the part number  …………..  from supplier

3579246  3589246  35-79246 35-792E6 357924-Blue  …….. Johnson or Johnston or Johnstone or Jonsson.

It is knowing and handling these subtleties which librarians excel at. Or in CHS, they Capital Library at. (second bad pun of the post).

Now the surface has been scratched relating to one or two small pieces beginning a reasonable “basic” subset of data, let’s be bold and examine a few more touch points. What about the CAD symbol or symbols to represent the individual connector? Are they part of the minimum data set you are looking to achieve before you would consider the part to be ready in your database?  

• Alternative suppliers
• Terminals taken and the wires that are valid for inclusion in the wires and in which cavities these can be inserted.
• Locking mechanisms attachment methods and strain relief configuration choices.
• Plugs and sealing parts
• Conformity to environmental control and recycling/pollution standards
• Dimensional information.
• Weight
• Extract of or link to official specification documents

Why is this detail important to you?

Because parts engineers and librarians are not just people too, they are pivotal to your success.

Simple five level elevator plan.

The customer I was visiting has guidelines for different levels of completeness of their library data supporting multiple projects in multiple locations. This is a handy way of breaking down the tasks so that the workflow steps are more manageable. Tasks can be split between locations and resources. Librarian task can be split so blocks of data creation and maintenance can be separated out and resourced with temporary help. Per project this perspective helps you to get to a believable % of task complete measurement.  The levels provide a simple way of organizing and executing harness component data management and infer the metrics which will be used to track progress.

The levels are:

1)      Base data and vendor reference data

2)      Design and manufacturing symbol approval

3)      Device transmittal layer (CHS footprint)

4)      Sub-component interrelationships (for example wire >> terminal >> connector)

5)      Models to support electrical simulation/analysis

Being able to measure means you can manage transition from one plateau of accuracy to the next. You can see the dimensions of your data management tasks. You can see it progress to a quality where it supports a high quality design. One of the things I like about this approach is that it acknowledges there is no fixed “minimum” standard. Having the library data good enough to get the job done is not good enough tomorrow when you need different parts information from the library. And then just when you think you have all the information about all the parts you’ll ever need someone will invent some more or want some more data associated with the existing ones or you will get a new product line. The concept of attaining a minimum doesn’t sit easily with the goal of reaching the best quality. 

Hurrah for the librarians. They contribute enormously to make the designs perfect.

 From time to time it looks like too much. All those things you should just know about CHS can be a little bit daunting.  But you join the little pieces of knowledge with the bigger ones until you become an expert. One of the customers I deal with has staff who guide designs all the way from concept and architectural studies, through systems design in detailed optioned logical drawing to Capital Integrator topology views merged with Mechanical CAD data and on to harness BOM detailing. Oh, and electrical simulation too. Oh and I haven’t really made it clear. That’s the same person covering all of that ground. Many electrical design processes instead fix and compartmentalize these individual functions.

Interdependence in interdisciplinary flexible teams is a common. It is rare to see a single individual having end-to end responsibility for a design. If you operate in a work group, the more you know about the requirements of people working upstream and depending on you downstream; the better overall efficiency is acheived. The less you know of the full requirements, the more chance of miscommunication in the hand off between one person and another. 

 My own job is more collaborative in nature rather than having sole responsibility for things. I’m part of a multi-disciplinary team of programmers, product architects, managers, quality assurance, customer support and training professionals. I rely on them, they rely on me.   

Here’s my recent experience with “things you just ought to know.”

On October 7^th I got an email from a colleague sharing a little piece of information about CHS. Where you run in CHS the  process to synchronize design data to a set of  harness designs a.k.a.  “build list”  you get a dialog shown below.  

Pass data from wiring diagrams to harness drawings

So another one of the things already I “just knew” is that since this dialog was introduced into CHS to select an available source design (topology integration) or set of source designs (wiring diagrams) you double click the check boxes on the left of the window and you single click the ones on the right. Just one of those things eh? I had been caught out waiting for half a minute for something that wasn’t going to happen the first time I went in to learn how to use this little piece of CHS Harness XC. 

 

My colleague informed the rest of the workgroup and I of  a little feature that has yet to find its way into the help file. Use the “Control” and letter “A” on the keyboard and that will allow you, where you are following the wiring diagram-led design flow to select all the designs on the left portion of the dialog.  A small time-saver.  

 

 Fast forward to November 23^rd  with a coworker from Mentor Graphics customer support   looking together on a Web co-pilot session at an issue with some data troubling a customer. Sometimes there are many dozens of wiring harnesses in a form of transport. How about a cargo transporter aeroplane for example? Or an eighteen wheel truck?  In our investigation we wanted to define a build list with every harness family named in it.

 

Defining harness build list in Capital Harness XC Ctrl-A selects all

The CHS graphical user interface (GUI) consists of a common set of programming objects.  So one of things I tried, knowing that “Control and A” worked in similar circumstances was to do the same thing in the build list manager interface. I knew it worked in the synchronize harness design dialog, and in many other places in the software.

What I was aiming to do was to set up for the first time a set of harnesses in a build list in order to synchronize them for the first time. For an entire car that was twenty-one composite harness family references to include.  

 Did “Control” and “A” work for me? Yes it did and it saved me perhaps 4 minutes.

 Small idiosyncracies and inconsistencies are almost inevitable in a large software system.  I have pointed out in the past when training customers, a trainee may be going to see more of CHS running on their computer day-to-day over the next few weeks than of your husband/wife/partner/significant other/domestic loved ones. Certainly that is what your managers hope when they send you to training.

 You spend time with a piece of software untill you know all the little ways and most of the tips and tricks – get  bonded with it. The observation about time spent with loved ones doesn’t hold exactly of course – analogies often don’t. I’m not suggesting that you should love CHS unconditionally and buy it a nice birthday present.

 Here’s what customers using CHS do to know more than they thought possible:

• Work as a team – the whole is greater than the sum of the parts. Worflow management in a modern complex organization is collaborative – everyone relies on everyone else – find out how and pay attention to the group dynamics.
• Learn from mistakes and inefficiencies and adapt. Ignorance is no defense in engineering.  Allow learning to come from what has gone not so good. Permit people to work out positive lessons learned and pass the lessons around to stop others going there.
• Participate in improving the documentation steadily over time – help files, technical bulletins, add resources and techniques like the Mentor Graphics communities. In Mentor Graphics we put time and effort into these areas. It is a shame to let that opportunity for learning pass by. Customers often develop their own “in-house” written material around their design process. Intranet, E-rooms, SharePoint and Wikis. Sometimes Mentor Consulting is hired to help out. Get yourself immersed in and particpate in documentation activity. When you can teach other people a subject it is the confirmation you know it thoroughly yourself.
• Push the boundaries. It is helpful to have access to a safe area, a “sand pit” where you can experiment without risk of inadvertently changing production data. This software reflects the complexity of the design tasks it accelerates. It is good to have a neutral zone containing a known set of data to “try it out first.” Be experimental in a safe environment.
• Share information with each other. I am fortunate that my coworkers are exceedingly generous with their time when they come across something interesting in noting it down and circulating their findinging amongst the workgroup. This saves the entire group a tremendous amount of time in the long run. 5 minutes here, 10 minutes there multiplied by 20 people over three years is really worth having. Reciprocate and initiate information sharing generously.
• Extrapolate and deduce from what you already know. Prior knowledge generally is predictive of how things operate elsewhere in the same system. Exceptions are nothing more than that – exceptions. Be optimistic, things are usually going to be the same as what you already know in the software.

There you have it. You can know more than you ever thought possible. You can extend your brain power. The good news is that it is a social and friendly activity, not a thankless solitary experience to improve your intelligence.

Am I saying CHS makes you smart ? It may seem a lit like that – but of course not. You were smart before you ever saw CHS.

I highlighted the powerful influence of customer lbrarians in delivering automation in the design of electrical systems’ interconnects using the capital suite of programs. Librarians get proficient initially through the ministrations of a trainer to guide them through the concepts of the software and how these apply to their working lives. I’ve also singled out the product management staff who convert their professional expertise and their personal understanding of users’ and marketplace needs into finished product. This group of people brings the new modules (e.g. Capital Architect and Capital Modular XC) into being. Afterwards it is work of the Educational Services Group of Mentor to author a training course.  Trainers have a challenging job and it is really well done.

And there are a lot of courses in the repertoire http://www.mentor.com/training_and_services/training/courses/cabling_and_harness/

The trainer who is going to deliver the course as a paid-for service is usually the main author, sometimes the only author. If that were all the accomplishment a person has to show for their working life “I wrote a training course or two) I think we should be quietly impressed. Distilling the countless features and the multiple patterns of use into ones which are highly relevant to the majority of users and interesting and instructive to the others for whom the task is only indirectly part of their role – that takes expertise and experience. Gathering it into a coherent package, trialling it, maintaining it is the ordinary part of the task of writing a training session. The real magic is in constructing something which has the potential to engage the audience.  Someone writing a training course is providing the potential for inquisitiveness to turn into professional effectiveness. The person delivering the training course has the goal of  realizing that potential from curiosity through to knowledge for the benefit of the customer and not for their own self-satisfaction. The Mentor trainers are great teachers who provide the environment in which the talents of the trainees can really shine.

Capital Harness XC - student workbook contents to show the comprehensive curriculum offered for one of the capital applications.

The participants in training courses come from a variety of cultural backgrounds. This is an interesting and stimulating fact of the business life for the trainers. I think it is good to acknowledge that their skills are not confined to international borders – which means their professional lives take them travelling as much as any sales or technical marketing person in the software industry. Perhaps more. And part of their job is to inspire more people, to aid understanding for people to whom English is a second language. To switch etiquette from the Asia Pacific deference to the European relaxed respect.  Sensitivity to the needs of students whether Middle Eastern, Brazillian or German for example is really important so that the training is optimally effective.

A tough audience here! Mentor Graphics Application Engineers brought their baggage, personalities and cultural heritage from many countries of the world and an interest in heckling the trainer.

A comprehensive mastery of the subject matter is a given, but there is actually a lot more to the remarkable skills of the trainers. In teaching something to adults, you are negotiating through the aspirations for success, the eager embrace of change through to the cynical and suspicious attitudes of people who don’t think the automation can fit their bsuiness process. There are as many motivations and likes and dislikes of people to the way in which they learn as they are people. Some students fold their arms and say “show me” and the person on the next computer may be skipping three exercises ahead and trying their best to make the software crash. You have to have a serious talent for communicating and a gift for listening as well as a gift for being listened to to have this job to flourish.  A good human beats a remote scripted session guide in mist categories.

Luckily we have some. Hip Hip hurrah for the trainers!

In an internal meeting at the end of last month I heard a fact announced.  In the total worldwide licenses for Mentor Graphics’ software for Integrated Electrical Systems the balance has changed. There are now more Capital Harness XC seats than Capital H Classic. The legacy system, the last generation software is gradually replaced by the new.  We are now at that stage where the front runner has been caught. CapH Classic was something I first saw used in production in 1997. For Harness XC to overtake it in number of user licenses in the time it did is impressive. From zero to parity in numbers is the same trajectory too for VeSys 2.0 replacing previous generation installations of VeSys Electrical Series.

Stability with VeSys Electrical Series and Capital H

On an individual level, many customers face decisions about challenging the old, the tried and trusted.  I think it is interesting to see what is involved in deciding whether your current tools compared to a new alternative shows obsolescence rather than value.   

So when do you upgrade in the near future, for example from VeSys Electrical Series to VeSys 2.0? When do you let go of years of good results, and look forward to years of better results?  The answer seems to be different for each customer.

Show and tell.

Business is fundamentally about profit, so my advice is follow the money for the evidence of when it is time to change. And here are some clues where to find the money – starting with where it usually isn’t hidden.

We have some money to spend … what can we buy?

•  A decision to change is almost never in my experience attributed to initiatives and future-proofing (we are working ahead of our competitors and investing as a result of R&D effort).  Very rarely have I seen an influx capital for modernization purposes result in a shopping expedition including cabling and harness software tools.  

I like the "slide rule" controls. The old technology nods to the older.

Why are we paying this money for old things?

• There are signs you cannot support the old technologies … when sunk costs are memories and continuing support of proprietary CAD engines are rising or stable but there is little perceived value in them. What do we get for this mainframe maintenance?  Old staff who knew what to do (the corporate know-how) have moved on and younger employees who want to work with more cutting edge tools, modern user interfaces. Sometimes you begin to have quality problems because the old tools assist you in elevating quality but did not automate the building in of quality into your product and the new hires are making expensive mistakes which you thought you had eliminated years ago.  

The status quo can cost dearly.

• As well as the melodrama of “return of the misbuild” the design to manufacturing throughput possible with your current tools may look like a steady jog rather than an exhilarating sprint.  Perhaps also managing  product complexity  is troubling you. Potentially you can have millions of option combinations are getting ahead of your tool and your people’s ability to cope. There’s are warning signs of a lot of money being spent on human validation steps, a lot of time being lost to eliminating errors. You suspect at first then are certain that you need something which will crunch more data much quicker and be much smarter about how that is done.
• And on top of the profit-goal business drivers, there are the increasing cost-of-doing business demands, for legislation and society evolves alongside your customer requirements and you find your resources doing “where used” & “what if” and hand-checking for recyclable, lead-free, withdrawn components. Another example of having to run faster to stand still in the market is to have to respond to warranty claims and recalls and you wish there is a better way of automating these things.  Perhaps with some updated software you think?  

The Vendor is pushing the new tools for some reason – I wonder why?  

• You are in a commercial partnership, or seeking one I hope with your supplier of enterprise tools. Does your vendor even have the latest stuff ready? What’s the view of your trusted contacts at your supplier?  Does your vendor allow the sales person to offer incentives the more easily for you to adopt the latest version?   

Advantage to incumbent supplier: 

• Your existing vendor offering the next generation of tools as an upgrade is a welcome suitor for your business generally.  You don’t have to be concerned so much as with a new vendor who may not understand the customizations, configuration and sometimes undocumented usage of the current solution. The vendor ought to have experience which is directly useful to you in transitioning to the next generation of tools.  

Cost of moving from the status quo is not zero either – so you better plan.  

• Is the migration path to the next generation an investment in time, training and other resources you can contemplate, something you have budgeted for? Changing over will take effort. Somebody somewhere surely has to do some work sometime even with modern impressive IT magic.  But cheer up, you are not going into a project to refresh your workgroup to get back the same level of efficiency, you are investing for a long term significant return because your team will be working at a higher efficiency.  

 General, indirectly financial motivations for moving to the next generation.

 I think we can refer to this for short as the 7-ish year itch?

• I have previously classified underlying requirements for software capabilities to fit your needs previously as  D) integration with other corporate systems,  C) produce the CAD outputs  e.g. prints   A) model your product intricacies and your design process and B) provide business value and return on investment.  Those are fixed needs every customer has. If your present tool set is letting you down on even one of these categories you have to act or have a high tolerance for business inefficiency.
• Tactical level requirements – if you already have something which has for some time been sufficient to your needs as described above  – are what you are going to notice. These are what are going to give you a competitive advantage, a better best practice than your rivals or comparable workgroups. If you keep up to date with the best in class tool capabilities or can recognize useful technology  when you see it, after about 7-8 years from your last deployment of tools and new methodologies in your organization there will be indications that the leading offerings in the market are different to what you are using.

The meantime since you last bought tools in the market, the tastes and techniques, approaches and technologies have changed.  In the VeSys Electrical Series and CapH Classic to VeSys 2.0 and Capital context the transition from flat-file and CAD engine moved to data-centered fully integrated graphical tools separating content from how that content is represented has happened. XML files are moved back and forth in a change management environment rather than import/export of structured and semi-structured text files for example. Similarly, another example is that drawing symbols are inside a database and under librarian control rather than external to the application lying on a file system folder.  You go for these advances not because you are a geek, but because they offer real, measurable benefits to your business/your customers. Better design change control, the promise of heightened quality.

Click on the picture for a bigger version.

After you follow the money, eventually you chase it down and catch up with it. 

All you have to do is capture the business case, the extra money you will save in efficiency. Shorter diagram development time, shorter wait times for processing, fewer corrections,  less time drafting,  built-in analysis and quality checks.

A well-run meeting is inspiring and fleeting.

Mentor Graphics internal meetings are usually jam-packed with facts. I wasn’t alleging the opposite . This particular fact that the number of Capital Harness XC licenses now being equal to Capital H Classic licenses intrigued me. Interesting where paying attention in meetings can lead you. I think more I should do it more often. Follow through from where the facts have originated.  Obviously I cannot pay more attention than I already do in all these meetings.  

Hope you found where the the musing led me useful. Comments and disputation very welcome as ever.

A community of practice is a way of organizing in a specialized field so people with the same interests can broaden their professional knowledge, learn and interact with others. Web technologies in the last 10-15 years have greatly extended the opportunities millions of people have to network, participate and experience professional growth. Capital and VeSys have gone there too and have a well established site

The way we give now.

For the Capital and VeSys product families Mentor Graphics through the IESD (Integrated Electrical Services Division) organization started some time ago a Web community presence, which is open to any registrant customer with a support contract running for their company. You can register under a pseudonym if that makes you more comfortable (so your competitors don’t get to see the competitive advantage your have in the tool). This has been a resource for customers for over 4 years, it is mature and well thought of.

One of the key advantages to customers using the Electrical System Design and Harness Engineering community is that the Capital and VeSys Product Managers are expected to check frequently for topics and contributions in their area. If you wonder what it is a software vendor’s “Product Manager” does and what’s in it for you – I wrote a post here  http://blogs.mentor.com/paul_johnston/blog/2010/02/15/latent-hero-series-277-the-product-manager/  explaining why these people are your friends. Like most of us, these people are busy, so email alerts are provided for them – the subject line of new posts will be presented in alerts and the emails are predicated also on tags assigned to posting. So here’s the first tip, construct a good title if you are posting, and make generous use of tags.   Mentor’s responses in these communities are moderated, managed and and tracked. Generally the monitors are happy with the speed of responses, and they believe that making this “behind the scenes” expertise available kind of directly to customers carries a lot of benefit.

In a sub-branch of the Mentor IESD Community site, these are shown as the popular tags for content and are linked to the postings.

There’s not a service level agreement stopwatch running on answering questions or responding, in this informal environment there is no undertaking to respond within “x” hours to any question. But as well as the development people there are also the worldwide practice of Consultants, Customer Support engineers, and the field application engineers attached to the sales force reviewing this community of practice. Here in Mentor Graphics we feel that this hang-out is beyond a critical mass of participants, and the organism “just ticks over by itself” in the words of one custodian.

What it looks like to be in a Community of Practice for Capital software.

 Types of Participation in the Community of Practitioners

For some communities of practice revolving around software the most active contributors may be skewed to the customer side rather than the vendor side. This happens sometimes because it is a simpler product in which it is easy to become an expert “front-to-back” and then share your enthusiasm and interests with other people.  With Capital, deployed workflows tend to be unique to customers so that your customer experience is not guaranteed to be transferrable to another workplace in whole, though certainly in large part it will be. I know this because I have seen people work for different customers re-using their knowledge of best tool practice.

Most of us who speak regularly with users of Capital get the impression there is a positive reaction to the Community site.  Analytics can be done with a site like this and there are around 200 customer users with an upward trend on the IESD site I am told. More are welcome, each new registrant will find something to interest them.

The 3 most popular areas of the Community of Practice site:

1. Electrical Design through to Harness Manufacturing Process including Electrical Analysis  – For practitioner issues in the core workflows of customers

2. Integration area  –  For plug-in  code downloads using the Application Programming Interface (API) of Capital.

3. General Discussion  – this is where people start off posting documents and asking questions when the category is uncertain

An area where there are proportionally more customer staff active than their representation at large in the community is in API work. This makes sense because programmers are much more used in their daily work to reaching out and collaborating to arrive at potential solutions for technical challenges they have.

Proportional distribution by main functional area over 150 Example Plug-in for functional area. Ratio approx.. 7:4:4 showing a bias in favor of Generative Flow and Capital Integrator assistance.

The more technical the area – we can infer, the more useful you as a user are likely to find the community spirit helpful.

Getting Started and getting benefit – joining the community.  

On http://communities.mentor.com/mgcx/community/harness?view=overview   – the communities site there is a really good search facility so you can find readily all material on a particular topic of interest to you. Most people who join spend some time finding their way around before progressing to making their own posting. If you are feeling bold don’t be inhibited –  plunge straight into debates and open discussion threads. You can choose to register and interact under a pseudonym so that competitor companies who may also be using the Capital or VeSys software cannot identify your activity or topics of interest and work out how you are deriving competitive advantage out of using the Mentor Graphics software

A typical starter use case for a customer joining Mentor Communities for Integrated Electrical Systems Design is to pose a question where Customer Support isn’t a place you would expect an answer. That’s why there are so many “How To” postings on the site. In fact, the answer to the question you have may already be out there – so search before you post is usually a good idea.

Worth your time

For new and upcoming customers I make a point of mentioning the Community as an additional resource in Mentor’s good reputation for supporting Capital and VeSys. It is your direct line to the experts, plus a searchable library of resources of best practices and advice, concept guides and approximately 150 plugin examples (and growing) examples being a drawing Part ID table and advanced design compare.  You can post a question and you can answer a question – both give and receive advice as a practitioner of Capital or VeSys.

What next after you first join – types of interaction?

The key challenge for the future is to keep the site content relevant to user experience and foster participation by satisfying personal customer goals for interacting and on a collective level meeting the community need. We see at Mentor customers who have the Capital software being deeply ingrained in their business processes and that is when the community participants go “deep” in their interaction and share their advice with other practicioners. We notice these because they seem to show us what we always thought would happen: the software let out in the world would be liked just as much as we like it!

We at Mentor also need to get disciplined to go a little against our human natures and also remember to be inspired by the most frequent customer interactions to the Communities site, where there is a steady stream of readers coming to the library of best practice documentation. It is a place where it is perfectly ok to be a consumer of the material. It is more than ok. Providing a place to access useful information and interact with experts and other customers is one of the main goals. Libraries are quiet places. You don’t have to interact with experts, it is not compulsory, reading the material and satisfying your need for a deeper understanding of the practical ways in which Capital software can deliver value to your business situation may be enough.

Relative size of Library held in the Community - Excluding plug-ins (250 best practice documents and growing)

Getting more involved, giving something back to the group.

Beyond a mode of participation consuming the collective knowledge, there are some easy ways to participate actively in small ways and do it very fast and conveniently. You can rate the documents and code examples you download and read. You can leave a short note providing feedback. And you can ask questions, have the moderators and seasoned posters to the community transfer some of their knowledge to a specific purpose. It is good to do this, it encourages your fellow members, and fosters further interaction.

The way it works with most community members is that after a time period where they read material and become connected with the community, you become comfortable with the idea of posting original material which you have created which return the favor to the community for the help you got.

I don’t know culturally whether this will make sense to some of the Capital users from different parts of the world, but the process is a lot like becoming a “Pub Regular” – you don’t ask to be part of the atmosphere of the bar, don’t follow a set series of tasks, you don’t have to pass any entrance exam, but after a while it is your Pub and you are part of the scenery there and you are a “Regular.”  Pretty soon new visitors to the community will be looking to you for advice and pointers about things you know through and through.

In the future there may be different ways come into the Community to foster inclusion and participation, possibly around some special events being organized. It will continue to be a valuable and growing archive of expertise, receptive to new ideas and new discussions, convivial and polite, open into the night hours – people visiting all the time, some staying for just a few minutes, others relaxing into the ambiance of the place, some approachable, some aloof – some garrulous and some politely declining to enter into lengthy interactions. Yes, definitely a bit like the village pub.

Rolling out an enterprise system is for many Capital electrical platform design software customers a multi-stage process. One set of tasks in managing the distribution of the value to individuals and the corporation is to integrate to the corporate IT infrastructure. This is done mindful of the needs to provide acceptable reponse to users, adequate security policy conformance, appropriate data backup strategies need to be in place, confidence in up time or availability for production users, provision of a trials/training environment.

Make management of the Capital IT infrastructure look effortless.

Actually that is just the highlights list of user expectations. There are many many more tasks in IT management to deliver a solid Capital application to users at multiple workstations – probably on multiple physical sites and probably in multiple countries on different continents. Systems and wiring design and manufacturing is a global business, so the software that supports that business is also by necessity architected to be used worldwide in diverse computer infrastructures.  The technologies of a military aerospace customer running Capital can be radically different from Mentor’s Educational Services’ virtual machine drop-in and go systems and data configurations for example.  But in all cases a common need, and usually the first one articulated amounts to ‘the software must be quick enough”  – no lags, no delays, no hiccups, stutters, freezes or lengthy waits.

That brings me to reveal what the  “P” word is. Performance.  My inclination has always been to taboo the word in meetings, and to have clients and colleagues find another way of describing their aspirations, and observations. Because in “performance” it is all too easy to chat about acceptable/unacceptable without the discipline of measurement. And then people become entrenched or adamant in their opinions rather than working on the basis of fact. Complaints are good, because knowing what you are unhappy about is the first step towards being happy. And the path to being happy about response time of a software application is knowing the timings. First the baseline or control  timing, second the same operation as you find it with a changed piece of the environment e.g. a workstation in Argentina and the same specification equipment in Poland.  You may be surprised at how many debates about the speed of software begin without reference to any standard measurements.

Timing tests with representative data are good ways to understand how your system is behaving. Harness XC processing is a common benchmark choice.

Of course our brilliant programmers and development experts designed a superfast code base! I can promise you it is very rare that any downturn in some processing speed is attributable, proved to be caused by inefficient logic in programming. Very rare over the last six years. So should be very rare over the next six years because Capital has a stable code base. Think about it, how likely is it that a programmer would write a clever routine to wake up after six months on a given version, yawn and stretch, take a look at the user base, see who is logged on with a Poilsh name and make their database inquiries run twice as slow as their Argentinian coworkers doing the same work.

Fortunately over the life of Capital there has evolved a body of knowledge amongst the Mentor Graphics staff who support customers’ deployments not just how to handle issues like these, but how to help customers devise a set of timing tests representative of the loads expected, and usage patterns specific to their needs. What’s going to be important to you rather than another company can be advised by the Mentor Consulting experts (intensive paid-for engagement and value-add)  the Application Engineer assigned to you  (best practice advice tending to specifics for your particular circumstances)  or via the Customer Support Engineers (responding to service requests with highly specific answers).   These people can help you avoid puzzlement and preplexity when someone comes to you with the general malaise “it’s too slow” and help you ground the problem definition in the real world, and give you practical steps to removing the measurable issues.

Useful helpers.

So what sort of operations are representative for most customers? What you shoud look at is not a big list of things when you are identifying a set of normal benchmark timings against which future measurements can compare (new hardware/ new software versions – amended WAN configurations etc.). The right P-word here is “Plan” – have a plan to measure these regularly.  Tracking these via a simple spreadsheet is commonplace – be sure to publicize the results widely so stakeholders know there is someone watching over this aspect of gettign return for the business from the software. It certainly does not have to be a lengthy list – but the more coverage the better the insurance!

Simple metrics like the time to retun an answer from a part selection dialog in Capital Design like this one are all you need to put the debate about response time in the Capital application on a scientific footing

You cannot manage what you can’t measure.

• Data Crunching through Capital Manager and back to the database repository and its manager: significant processing options performed frequently – Harnesss Processing in Harness XC for example on a small, a medium and a large example of your product data or a representative approximation thereof.
• Pulling Data Across the network: open and close and save tasks on your designs (e.g. schematics topology designs, formboard drawings) – the most common things which your users will do  – so any change in these timings will be noticed first by the user community. Include logging in to the system in these tests. This exercises the parts of the system where data is buffered up for local client work.
• Common editing and design operations. Interrogation of the library items (devices & other parts definitions and symbols) once you have opened the designs. This tells you what the normal user experience is going to be as they work day-to-day.
• Passing on data from the Capital application to other parts of your IT environment: Perforn some popular print or reporting functions.
• Capital data exchange: Import and export of project information – although this is a rare occurrence these operations are probably the highest “stress” you can present to the system. Keep a data set constructed just for this purpose if you can.

Whether the list of tests contains multi-user weighted tests, accumulates results from different sites is often up for grabs. Your decision whether you want to go deeper and look for comprehensive results or settle for an acceptable minimum.

My view is that the user community will thank you for depth and attention to detail. And you will thank yourself for anchoring any performance discussion in reality by providing factual, observable data.

Capital software covers the automotive electrical design process from early conceptual architectural design through product engineering. And onwards too through manufacturing engineering to manufacturing assembly. In this entirety one would expect sophistication is needed the ability to handle complexities, nuances and variations. Doing this while sustaining a user-friendly reputation has to be achieved to keep users happy.

 What do you want?

Finding your way around functionally rich software takes a combination of knowledge and inclinations. There are lots of methods writers of software utilize to make that journey from first impression to lasting familiarity a smooth transition. A focus aspect of the design of computer systems is known by the acronym HCI – Human Computer Interaction. To most consumers of an application – you are more interested in the benefits of using the system rather than how clever the system is in terms of how it interacts with you. Your judgment of whether software is good or not is quite rightly not usually a conscious one – you should not have to debate the issue. Can I get my job done and is the experience one where it is easy to do so?

Visualization.

When you are designing a transportation platform, there can be hundreds of signals, thousands of wires, hundreds of wire harness part variances, oodles of options, dozens of Electronic Control Units, a smattering of ground paths, a maelstrom of engineering changes to many scores of diagrams. It helps that you can pick out the things that you want to concentrate on quickly. In software applications – if visual cues are not obviously different it will be difficult to distinguish between things you as a user really do need to discriminate between. In Electrical platform engineering the visuals – the release prints are really important. Those pictures are summaries of many thousands of words.

Hence when drawing standards are being decided, your company may choose to identify wires for power and ground by different and obviously distinctive colors on the schematic. Furthermore when drafting or generating service and technical publications diagrams using Capital Publisher you can see a case in legibility and accessibility for rendering these schematics showing the jacket cover of the wires in the pathways of the wires across the diagrams.

Conductivity pathways are more prominent if shown in different appearances.

Another example of reducing the ability to misinterpret your data as visualized on the electrical diagrams is the technique of tabooing names or elements of names which have potential to confuse. So, for instance it is common to have letter “O” disallowed in reference to wire naming, or naming of other objects such as devices, harness mechanical items or cavity names. This obviates the confusion between zero (0) and (o or O). Similarly Z, z, I (upper case i), l (lower case L) are frequently not included in permitted names in order to avoid confusion with numerals 2 and 1. B may avoided because of similarity to 8. You pay attention to detail in the textual data you use.

Lookup lists in Capital – Project resources and rules and constraints.

This is part of the “prevention not cure” philosophy which leads one to favor creation of permitted lists of device, connector or harness family names – or leads to the applying of rules so that you must have the revision suffixes of your designs and diagrams – your child harness parts for example – correct by construction. It is best that there shall never be a hint of a question of a doubt in your mind about whether that is a dash or an underscore in the harness part number. And there will not be any room for doubt, nor a need to check if one or other or both are by rule excluded. That’s what correct by construction means and how quality improvements delivered.

The Capital User interface (and VeSys 2 too for that matter) has a multiplicity of these features. There are also some other really good practices for showing what you want to see (fade in and out of manufacturing process sub-assembly/module views in Capital MPM/TVM for example. Additionally highlighting of pathways, highlighting during for simulation, the trusty zoom to, a one-key open associated of sheets – all fast techniques of getting to your required sub-set of data quickly.

New things added in new versions – old stalwarts still serving you well.

My favorite recent addition was last year’s introduction of “show circuit” in Capital Integrator – an implementation of the Capital AutoView technology which came out of users’ welcoming response to a similar “show-me” rendering feature in Capital Publisher.

Cutting down on the amount of available information – de-cluttering – is for a lot of engineers an important aspect of being efficient. Just enough information is best. Too much will increase the risk of ignoring something significant. That’s why the Design Rule Checks provided as standard can be pruned back using Capital Project so not all of them run, or run and give indications action is imperative. And when you are examining with the output you can yet further filter to better prioritize your response and understand the importance of the feedback you are getting.

The display of Design Rule Validations for a schematic can be dynamically changed as you filter the list to concentrate on the important ones to you

Consistency of the “look and feel” and the detail of how you interact with the data sets has also also achieved through the different functional modules of Capital. You can expect to see the same Part Selection Dialog in Capital Harness Manufacturing Process Management as you use in Capital Logic for example. This means that wherever possible the short-cut keys, the print dialogs invocations are standardized and the benefit is that if your people have responsibilities which cut across traditional design cycle boundaries (the harness person is encouraged to explore the systems designs) there is a minimal training overhead – perhaps none in some cases.

Take a test for which there is no pass mark.

It has been remarked by a colleague recently that my approach to using Capital is to concentrate more than average on using the right mouse button, and in terms of keyboard entry I find my way around via the tree view filter a little more than most other users do on average. Also I use the ALT- key combinations to invoke functions more than most. So as an experiment – given that I am less inclined to make use of toolbars, I took a toolbar for adding diagram objects into a schematic from Capital Design and pasted it into a blank page and tested myself as to whether I could “run the table” of getting the function of each of the icons.

16 of many functions collected in a toolbar. In the Capital Logic application you can simply rest your cursor over the item and be told what it is by a call-out message

Bear in mind I am an expert at this so I should do pretty well you would think. So out of sixteen, I guessed correctly thirteen. If you are trying this for yourself and bagged a superior count, well done for your achievement if you had more than me – and for reasons explained later, well done if you had fewer correctly identified than I.

The item furthest to the right is the icon for adding graphical elements like lines, circles and other shapes to the drawing. It was the three to the left of that which I gave up on being able even to guess at. The drafting purpose of those icons are actually: to add overbraid; edit/add assembly; and finally to make/modify a block.

Now comes my excuse for getting some wrong. Not that the assembly icon (looks to me anyway) like a blue audio cassette from late 1970’s. Nor either shall I complain that for some simple picture of an already abstract concept – like one of those I got wrong was add a block – it is difficult to get an effective further abstraction of an already abstracted concept. There’s only so much help a picture can give you. Try designing an icon denoting phenomenology and you’ll see what I mean.

Mix tape not icon

No – here’s my excuse – those three are ones that I seldom use. Most of the work supporting customers is done where blocks, over-braid definitions and assembly items are not used. Icons are as much memory aids. Not for initial cognition but re-cognition. That’s my excuse and if you only have a few out of sixteen correct then I guess you don’t draw schematics with Capital Logic much at all. When you do get habituated to abstractions – it doesn’t take long to adapt to EEEEE’s of UUUU’s conventions – you’ll do well or better than I did.

Answers to the test

Here are my answers so you can check your own if you want to play along. I allowed myself 3 seconds only for each answer – any longer indicates a greatly reduced chance of guessing right. And there are no prizes for beating me, other than the glow of satisfaction knowing you did better than someone who may be supposed to know all 16 via subliminal fanaticism.

• Make parameterized device & characterize pins later
• Insert plug
• Insert inline
• Insert receptacle
• Ring terminal
• Add splice
• Add net conductor
• Add wire
• Add highway
• Add shield termination
• Daisy chain something … hmm multicore shields phew got it.
• Make multicore
• Don’t know (overbraid)
• Don’t know (assemblies)
• Don’t know (add/edit block)
• Draw graphic shape with no electrical content/meaning

“We certainly want your ideas and our goal is reply, enrich and decide on what we should do with any idea as soon as possible. This does not mean that we are going to implement every idea, that is not possible for a number of reasons but mainly due to resource and our desire to ensure that we are answering our customers’ principal business needs 1st.”

This is a quote from Andy Reilly, Product Marketing Manager, IESD  – from the IDEAS website.

In this final piece in the mini-series, I will review how to give your proposals for enhancing Capital the best chance of success, from an insider’s point of view.

The Numbers Game of Enhancement Requests.

Assume this about your requests plus everyone else’s: few will make it into the software. Exactly how many, what proportion reach delivery varies. Contrast enterprise class PLM and 3D CAD systems and some specialist commercial software for packaging inventory you bought from a small company and you are their first major customer.

Of course your enhancement requests are different. They are better thought out, more brilliant, more attractive and more intelligent. Nobody can argue you don’t have a close affinity for them.

In reality you need to make your initiatives inspiring to others, and clear frontrunners to extend already extensive software functionality of Capital. Requirements drive software features and software features get added into Capital at every major release. That means lots of new functions and features. Not to participate in the Mentor Ideas way of recording your requirements means you are choosing not to have your voice heard. You are letting other people represent your interest.

These following numbers aren’t the true ones – I offer them as a lesson in expectations. Let’s assume that on average six enhancements a week are being added by new users around the world and history shows two per week will be taken out of the pool and actioned. This leaves four, or which 3 are not going to make it into the software and one a week is classified as unsuitable – perhaps because the software already does what is requested, or it is a duplicate or a very close neighbor of an existing proposal already in the system consolidated into the prior.

Formal Stages of an Enhancement Request for Capital as described on the Mentor Ideas Website

Face the truth: Take Comfort that I wasn’t rejected, I was simply not accepted.

Occasionally an enhancement gets classified “out of scope” which means it may be an idea, but it is not an enhancement. It has happened to one I sponsored – something which was supposed to be designed into the software which wasn’t realized properly and was fixed . Another out of scope reason is that Application Programming Interface (API) provided in Capital delivers the function.

Like most software producing organizations, IESD does not consider the un-met enhancement requests backlog. There is not an intention to do everything requested. There isn’t infinite resources and volition to do so. This is for many reasons, for example extending to new functional areas rather than enriching an already acceptable function set of a stable product is the preference.

Who cares about measurements?

If you care enough you can put numbers into the benefits from having a future improvement – things like time saved, quality issues eliminated etc. In first in this mini-series of postings I have offered a few pointers to Capital customers how to present their requests more powerfully and persuasively. Well constructed proposals have better chances of appearing in a future release. If you prove to yourself with fact finding and metrics that your thoughts about how software functionality could be extended actually does translate to tangible benefits to your organization you prove also it is worth upgrading swiftly to a later version of Capital.

Mentor Graphics cares too. Product Managers  are responsible for the overall product quality and attractiveness to potential and actual users. From the other side of the customer-vendor relationship they are also working from facts where they can, and opinions where they cannot.  A description of the type is here http://blogs.mentor.com/paul_johnston/blog/2010/02/15/latent-hero-series-277-the-product-manager/  Tap into their concerns and motivations.

One area it is difficult to establish metrics for is for is the uptake of enhancements. As a matter of course customer initiators of new features coming into the software get notification when the new release is imminent. How soon newly introduced enhancements get into productive use at customers is a different story. See http://blogs.mentor.com/paul_johnston/blog/2014/05/12/why-would-you-not-want-to-use-the-latest-capital-software/ for motives to go to later versions.

When you see an enhancement requests you have nurtured coming into the software remember to close the feedback loop with Mentor Graphics. Let us know you have adjusted how you work for a new feature and report whether the expected benefits were realized, or exceeded.

The value of user activism in promoting your agenda.

There is a very simple method used by the Mentor Graphics organization understand what a customer’s business needs are. It is called listening. To listen is an often overlooked form of interaction. Engage with the Mentor Graphics contacts you know to explain things to them. Go to the trade shows, the IESF conferences, User to User meetings. One of the benefits of accepting any Customer Advisory Board or Group invites is that you will be participating in a good platform for collective representation which emphasizes your enhancement requests.

Advocates – the many and the few.

A collective voice amplifies your case. To enlist the support of powerful individual voices and brains can help also.When Mentor product managers attend Customer Advisory Boards, IESF seminars and User to User meetings a unified message from a set of users is intensely memorable. Experiences where users interests are represented in groups sticks in the minds of Mentor Graphics product development managers.

There is also a lot of good that can be obtained from utilizing Executive- to-Executive level contacts to promote a desire to have an enhancement included in a future release. A message conveyed at senior management levels across from customer to vendor can do much to accelerate the consideration of an enhancement.

If you are considering elevating the message to high-level meetings of course it is a tactic which needs you to be comfortable that the subject of the enhancement request truly is significant and substantial. Neither you nor your software vendor wants to promote a new feature which has disappointing up-take or yields marginal improvements. An executive sponsor may hold you to account for your advocacy of something which had a poor return.

Elevated presenting of the requirement at an upper management meeting should not short-cut the technical evaluation and validations needed in the software development process to deliver a quality end product. Remember that fully justifiedideas give you a better chance of getting them accepted. That still holds even if you have a figurehead manager who will take a headline description of an enhancement you want and champion the idea with all vigor. By the time it gets to Product Management and Development Engineers to turn this request into software code the detail must be present.

Vary your tactics to promote different categories of enhancement – getting to be first amongst unequals.

It may be apparent to you already – in case it isn’t – enhancements are not all equal. Enhancement requests are different types from different pressures on customers at different stages in the lifecycle of adopting Capital. There are different typse of user who collate and records requests. Typically the users who make and promote these requests are expert users, who spend a lot of time using the tool and particularly the system administration parts of Capital. Therefore there are proportionally more Capital Project, User and Library and Integration Services requests than there are users of these modules e.g. compared to Capital Logic, Capital Harness XC.

The vetting, acceptance and delivery of enhancements is not a process where “all things being equal” is a phrase that makes sense. Giving your proposals the best chance of making it through the process starts with recognizing this and deciding you will do things to make your enhancement ideas more prominent and compelling.

1.      Upgrade type enhancements linked to the user environment beyond Capital.

A type producing numerous requests is to address environment support and compatibility issues. An example is a call for Chrome version “X” with Java Run-Time engine “Y” to be supported by Capital Publisher smartclients. Also included compatibility requests or interface schemes for corporate security and privacy of user information. Likewise calls for compatibility upgrades to Capital’s many adapter integrations or bridges – like to Mechanical Computer Aided Design (MCAD) and Product Lifecycle Management (PLM) and even system & workflow based change requirements collation and tacking systems notably IBM Team Concert using the IBM Jazz user interface. Modified new versions of these systems of data target or source produce enhancement requests to increment Capital functionality.

You will be best placed for success by early discussion with your Mentor team representatives and the product development staff at Mentor Graphics IESD division.

2.      Requests which are asking for improvement and modification of something already in Capital.

In this category – pertaining to the user interface, processing steps and the underlying data model and storage of information there some quick tests you should subject your proposal to assess if a realistic chance of success exists.

Test for comprehensiveness. Let’s say you see an opportunity in the part selection dialog (PSD) of Capital to do something in a more appealing way. The PSD is in Capitals Logic, Harness XC, XC Modular and Formboard, Insight, Integrator, TVM, MPM. Change it for one, you change it for all – thus lots of coverage testing of a change. Plus all users of all those modules at a new version with a different functional outcome will need to be informed/trained as to what to expect. Imagine a thousand users sat in a huge room, used to doing things one way and then judge whether the improvement you advocate is still significant, or will be welcomed.

There’s a down-vote as well as a promote option on Mentor Ideas for IESD. It is not often used, but if you see a proposal which would disadvantage the way your company works if realized, say so. Consider when you offer your own schemes whether it may cut across the wishes of other users in other companies.

Capital is a highly configurable software system – and in many aspects of the user interface there are opportunities to modify what appears. In PSD case librarians can do a lot to prepare data or pre-filter user choices. Assigning properties, domains and even scoping attributes to components for example may give the flexibility you seek. It may not get you exactly where you would like to be in the best of all imaginable solutions. Check there is no viable alternative configuration step which will alleviate your concerns.

3.      The type of enhancement request which relates to a newer part of the Capital Product family.

As a rule of thumb expect to have more chance of success with a newer part of Capital. Once into “maintenance” mode – development organizations are more likely to be shy of introducing improvements. The thinking is the market has accepted and got used to the software the way it is, and so many ideas’ merits will be somewhat suppressed in priority by this. To developers – stable code inclines them to think “it ain’t broke”. So make your argument forcefully if you think it is.

Capital modules of in the first 3 – 4 years from their initial commercial release tend to attract more requests for enhancements. Capital TVM and Capital MPM and Capital Modular XC are therefore good targets right now if you have some improvements you want to suggest.

4.      The type of request which is popular and benefits numerous users.

Mentor Graphics is in the business of making customers happy. More users at more customers, happy piled up on happy.

I remarked earlier that there is a disproportionate representation of sysadmin and librarian functional enhancement requests. Exactly how does one count users? Remembering that not all enhancement requests are equal and will not be treated as equal, you should wherever possible quantify the number of users who will benefit. Prioritization by Mentor of the requests which express the greatest good for the greatest number is what you should expect.

A modifier to this utilitarian principle is “the more users whose purchasing power is extraordinarily potent the better.” VeSys customers are numerically more plentiful than Capital customers, but Capital Users are very numerous, clustered into bigger companies, represented by more expert users and outspend VeSys so Capital is more bountiful in Mentor’s view. Investigative journalists follow the money trail in their work, software product managers in for-profit companies do something similar. They pay attention to the revenue stream, just like you, the commercial users of their commercial product do.

Prod the product managers by indicating the clear refreshing value stream of happy on happy and repeat business flowing like revenue down a prosperity mountain.

So let’s all be happy. Happy New Year for 2015, and happy new release for Capital Users for the 2014.1 version.

The previous blog described why software vendors build out their off-the-shelf products with arrangements for functional extensibility. Also I reviewed what motivates companies designing and manufacturing transportation electrical interconnect to expect, ask for and then subsequently use an Application Programming Interface (API). Now, drawn from my experience of Capital’s deployment at customer sites around the world, you can read about some reasons why taking advantage of Capital’s extensibility is a constant and how that worth is appreciated by users. It is worth reading because the benefits can be substantial to your company.

Essential for joined-up processes

Software applications which accomplish tasks as if they were independent of a need to interact across environments or domains do a disservice to the companies which in a true enterprise environment require interoperability. Enterprise applications have to interface with one another in order to be successful within a modern business. Data needs to be shared between multiple applications so that it can be tracked and traced throughout a product’s development lifecycle. These applications also need to be extended to ensure they meet the particular customer requirements. Flexibility includes the capability to model and store the business rules and what is referred to as the Intellectual Property (or IP for short) use in the design methodologies. Here is often some of the core private foundations of the competitive edge you have over rivals.

Applications talk to each other through data transfers in and out. Processes for import and export are handled in a part of the system called Capital Bridges. Services for data take-on for designs, services for library import, merging and blending are presented in user interfaces based on the extensibility technologies of Capital. When you expose the data model so it becomes interdependent for information to what is happening in other systems you get in return plenty of benefits.

Enabling transfer in and out of data without the formalized arrangements and structural support of Capital Bridges’ licensed products like those to Catia and Creo and NX Mechanical Cad systems are based on extensibility principles. Sharing of data is one set of benefits – using events and data conditions to trigger actions back and forth between systems is another advance which users are increasingly coming to expect. In Capital this is achieved with the Web Services links. Furthermore, special data conditions – based for instance on the way you have chosen to customize your mechanical CAD models with property tags – can be the subject of specially written bridge processor extensions done in-house or by bought-in talent like that provided by Mentor Graphics Consulting division.

Mentor Graphics Consulting experts do not get any more access through the API or extensibility provisions than your in-house staff do, it just so happens that they are likely to be more experienced, having worked on several similar projects before yours. Your own people will perhaps be partnering with consultants to learn from their experience to make the best time to productivity.

Why do you choose to use the API?

Every organization has special requirements, and I am sure yours is no different. One maxim I use with customers who are adopting Capital is: “it is not a matter of whether you want to extend Capital or not to meet your specific needs, the question is, how far do you want to go and how often?”

Typically, adapting the extensibility features to their individual needs is one of the more innovative experiences of deploying Capital for customers. Plans for extensibility and making plugins stay fluid as customers get into new ways to deliver innovation, in the same way the business of design and progression to manufacturing is done. It is also normal for this innovating phase of picking up use of the API functionality to take place after the first wave of deployment projects’ data populates the databases. One of the exciting yields for stakeholders at this time of using plugin reporting and validation is to explore new ways to understand your business, as you explore new analyses of your data, which arise, from your business activity.

Customization vs. Extensibility

For some companies the word ‘customization’ is taboo. The combination of enterprise software and a history of customizations entail past experiences they do not wish to repeat. Production deployed software may be perhaps 10 years old or more and has not been kept up to date because of the level of customization. Defunct hardware and unsupported operating environments represent a business risk. Capital does not carry these risks with it.

The notion of extensibility is different. The Capital API is designed detached from the core software. Extensions can be created freely without fear of interfering with any of the core tool functionality. This means that future upgrades to the software can occur independently of any plug-in development. Upgrades do not carry a threat of service interruption or denial.

Application Programming Interfaces are a way of producing functional additions run inside the larger commercial off-the-shelf application. The best examples of API’s therefore retain all the validation and control (like security layers etc.), whilst still allowing customer innovation. Don’t be fooled into thinking this is an abstruse subject. It is intensely practical. Real problems are solved and there is a happy situation of multiplication of benefits when this becomes a mechanism for innovation. If your API sidesteps, circumvents, ignores, or sneaks around your quality and security processes for example – that can force on you tough lessons learned about allowing access to sensitive data. Capital will not do that.

Two examples of how the API is useful.

Here is an example. A manufacturing plant will only accept the harness BOM when it matches a certain format and includes some additional attributes. Off the shelf Capital provides ways to modify, or alter, a table or report. More often than not there is not enough flexibility to provide you with the exact format required. However let’s speculate that there is a special set of conditons for the BOM format which cannot be met. With very little effort, a Java programmer could create a custom version of the BOM that can either be printed on the diagram, or created as a static report. That plugin can be added to the set already provided in Capital HarnessXC. Not only is a difficult case quickly closed, the table can be automatically added to the face of every harness that goes to that factory thanks to Capital’s styling technology.

Here is another example. You have a requirements that no multiple terminations can be present on a sealed connector, or disallow placement of connectors of a certain sub-type in hazardous or harsh environment areas of the vehicle. Let’s assume too it is unlikely that any commercial tool has a validation “out of the box” to detect these situations – Capital Logic has around 70 out of the box but let’s go with the assumption. It will be the work of just perhaps an hour or so, for a java programmer to author and apply this check as a custom Design Rule Check in addition to the set already provided in Capital Logic. A tricky localized use case is swiftly deal with – and you can also determine that a design cannot be saved or released if there are cases of wiring that breaks these rules.

The above picture is from my Capital system, and I’m at the moment using just over 50 API utility extensions.

What do you invest in to use the API?

I have asserted – a programmer familiar with java (not an expert programmer) will take “perhaps an hour or so” – and if this person is hired on as a staffer in your company, or hired from outside as a consultant or contractor that attracts an hourly rate. My observation is that usually a good slab of API programming time will be spent on creating new DRC’s. Checking experience with other colleagues, their observations are that making special reports is often the priority that customers work to. And of course the user time specifying and refining the requirements, acceptance testing the code is time you may account for in your tracking system as not actually interacting with customers. These investments in future productivity are well worth it. The value in removing errors and thus eliminating quality problems, automate reviews, supplement documentation

Usually it is a good idea also to have someone write up the usage methods for the plug-in code, which is used in your system. This investment in process definition with your software tool also ensures you minimize training overhead.

In-house or external resources can create and re-purpose code quickly for you

Time is money. Talk is cheap. Talk takes time. So either talk is not cheap or time is not money.

Also reducing the time to productivity is the copious reference documentation resources which are installed with Capital. Other API’s can sometimes provide a toolkit without anything other than the barest of instruction. Capital is different.

You have a plethora of printable, readable material on all aspects of the subject. Supplemental resources on the IESD community site come from Mentor Programming and Product management people, to which any customer with a current maintenance contract may contribute. If you are the person actually doing the programming, as a “last last” resort after looking at the manuals and perusing the examples and advice from the practitioner friends out there in the community, phew …. well there might be your worst programmer fears coming true and you actually have to speak to someone on the phone or have a web meeting and talk. Hear some nice polite and generous guidance from a fellow human being.

Your people using the Capital API are valuable to you, so Mentor equips them with the best.

Your own IT experts historically have been solving practical business problems with IT tools and solutions. Perhaps as they have crafted integrations, extensions they have been used to languages and environments which are more suited to Microsoft Office documentation solutions perhaps rather than enterprise data-store-scalable professional tools. The Capital API being tightly coupled into the corporate design environment and locked in to IT governance policies which minimize your exposure to business risk is also an aspect of the unexpected benefits you get for choosing this way of working.

It is a safer, faster, cheaper method of extending and personalizing your Capital repertoire. Professional services costs are under control – the know-how of your business is kept firmly in-house. Empowering your talent pool with enterprise class tools and allowing them to trade up from the basic scripting/macro building technologies of brute data manipulation in office automation products is good. Very good for career development and for giving your valuable IT employees who you want to retain an interesting job to do now – and learning platform-agnostic Java if they do not already know it – which will usually have an impact for other domains than Capital too.

Activation by license.

The operation of the API is governed by a licensed product called Capital Integration Server (CIS).  All additional coded plugins depend on the presence of this license for a user to have the chance to load and run them.

Design Rule Checks, Design Inspectors, custom actions, custom-designed tables which appear styled into the diagrams etc. have a running CIS process as a prerequisite. Likewise any pluggable authentication programs or web-service based sub-processes consumed or hosted, like those involved in event publication and subscription triggering. Thus does this purchased CIS license underpin integrations between Capital and other systems – enabling for many customers a tremendous amount of automation and validation, yielding a continuous return in efficiencies and elevated product quality, decreased engineering time.

These are the things you can write in the API which will help Capital users every day they work in the software.

 Used by people with time pressures.

Extended functionality achieved by using the Capital API is, well, not just an extension but an addition to the value you get from Capital as a user. If someone has given you a custom DRC it means that you are confirming, without manually checking through a data source, quicker and more accurately the state of your data, and therefore building quality in to your product. Data can also be augmented using the API – again a faster and less error prone process than using manual means. Data can be transferred or pulled automatically – for example to a Product Lifecycle Management system (PLM) – saving staff time and effort and ensuring compliance with corporate governance directives. Less time doing things which don’t directly contribute to the electrical system design, less time “minding and ministering to the machine”

If you are a Capital user this means you get more time to do the job you are paid to do and are good at and enjoy doing. More of what you like to do. Fewer things you have to do which aren’t what you like to do. The more time you spend creating data, and the less time you spend validating it, the more productive you will be and the business as a whole will see the benefit.

Anticipation

Now for the future. The last blog began by a glance over the shoulder to the past. This week, the perspective is forward looking.  And a new departure – a European location from which to make a posting. 

I’m in the Mentor Graphics office in Newbury, England and earlier in the week spent some time in the office in Altrincham farther north.  Preparations are in full swing for the release of 2009.1 and whilst I download a few pieces of environment and cannot proceed with a tutorial exercise, I can share a few details of what’s new. But not much in the way of detail, as the official list of what is contained in the release is concealed from the world at large untill public launch date. Here are the details I can reveal. It will be good. There will be additional new things.  Er, that’s about as far as I can go.

As well as the content of the new release I’m getting to know some of the ins and outs of CHS Harness XC styling capabilities a little deeper than I have already experienced. It is impressive. Tomorrow is Capital Analysis day. Analysis models. So the option of a modeling career is possibly open to me – in a sense. Yesterday also included a deep dive into the generative design flow and an exploration of the power of the Composite Wire Synthesis and the Abstract Wire Synthesis processes, CWS/AWS. In the future there will be no lessening of the pace of three letter acronyms. Mentor’s Integrated Electrical Systems Division programmers are devising new ones. 

Good opportunity also to hobnob with the colleagues from various parts of Europe, India and with familiar faces from North America who have also travelled over. Mentor Graphics divides staff into “factory” and “field” – distinguishing between those who are on the production side of the software business and those like myself who have more constant customer contact. Which reminds me, as well as the training and technical updates, there are a few emails from the jolly fine people whose success makes my continued employment happen. So I will go and deal with the half dozen emails which have popped into my inbox in the last half hour.

A lot in Electrical CAD and manufacturing quality hinges on data accuracy and completeness of the library data. From the carrion-crow-like perch of someone supporting design automation software, the immense and patient contribution of the ECAD librarians is often missed.  

A couple of co-inciding recent events brought me to a renewed understanding of the significance of the work librarians do. Those 2 events were a visit to a customer, and  reading a book. The book, I picked up at a church hall used book sale. Quality is Free – the Art of Making Quality Certain. It was first published in paperback in 1980, ISBN 0451624688 by author Philip B. Crosby.

This book has a few things going for it, one of which is it is a Mentor publication – but no relation to Mentor Graphics. The Mentor Books – New American Library, is, or at least was then, a sub-division of McGraw Hill Publishing. For a chance encounter it was interesting reading and a good slice of luck. I think it is out of print now. The domain the book covers is general industrial production and as well as offering  plenty of nuggets of straightforward wisdom like “act now for reward later” Crosby goes into convincing detail about the patience required to achieve quality improvements.

I like that a librarian themed blog post involves a book. Next time you go into a public library be sure to wish the person behind the counter “Many Happy Returns”

Empowering librarians:

A high quality electrical parts library to support wiring designs is achieved first by putting in place the right resources for the right length of time. But a close second is senior management makes the responsibilities of librarians untouchable and uncompromised. Giving librarians the authority and autonomy to manage their domain is highly beneficial. A division of labor has been popular in for profit organizations since mediaeval times. It is a winning formula. Librarians have better expertise and the experience in component data management than harness design engineers for example, who to give them their due are far better and more valuable as designers than the librarians may be. Better quality data in the library is not a finish line to pass and then forget about and go on to the next thing, it is an ongoing commitment.

Comprehensive and complete data.

Imagine there is a missing electrical connector in the library. Is the quality problem of the part not being present solved by the part reference being added? If you think at first blush that this is the end, then consider whether for electrical CAD purposes a basic definition really will suffice. Depends what you mean by a “basic” set of information might be your reply. What to include in the set of basic information then? A majority of engineers may want an accurate cross-reference to who the supplier of the part is additional their own internal part numbering system. You want to know where the part can be sourced from. If that part reference, any part reference contains separation or position significance coding, well that’s got to be accurate too for consumers of the data down the line.

Yes, accuracy makes a tremendous difference:

The CHS system has a lengthy list of off-the-shelf design rule checks which can be supplemented through the extensibility features.

What’s the difference in the part number  …………..  from supplier

3579246  3589246  35-79246 35-792E6 357924-Blue  …….. Johnson or Johnston or Johnstone or Jonsson.

It is knowing and handling these subtleties which librarians excel at. Or in CHS, they Capital Library at. (second bad pun of the post).

Now the surface has been scratched relating to one or two small pieces beginning a reasonable “basic” subset of data, let’s be bold and examine a few more touch points. What about the CAD symbol or symbols to represent the individual connector? Are they part of the minimum data set you are looking to achieve before you would consider the part to be ready in your database?  

• Alternative suppliers
• Terminals taken and the wires that are valid for inclusion in the wires and in which cavities these can be inserted.
• Locking mechanisms attachment methods and strain relief configuration choices.
• Plugs and sealing parts
• Conformity to environmental control and recycling/pollution standards
• Dimensional information.
• Weight
• Extract of or link to official specification documents

Why is this detail important to you?

Because parts engineers and librarians are not just people too, they are pivotal to your success.

Simple five level elevator plan.

The customer I was visiting has guidelines for different levels of completeness of their library data supporting multiple projects in multiple locations. This is a handy way of breaking down the tasks so that the workflow steps are more manageable. Tasks can be split between locations and resources. Librarian task can be split so blocks of data creation and maintenance can be separated out and resourced with temporary help. Per project this perspective helps you to get to a believable % of task complete measurement.  The levels provide a simple way of organizing and executing harness component data management and infer the metrics which will be used to track progress.

The levels are:

1)      Base data and vendor reference data

2)      Design and manufacturing symbol approval

3)      Device transmittal layer (CHS footprint)

4)      Sub-component interrelationships (for example wire >> terminal >> connector)

5)      Models to support electrical simulation/analysis

Being able to measure means you can manage transition from one plateau of accuracy to the next. You can see the dimensions of your data management tasks. You can see it progress to a quality where it supports a high quality design. One of the things I like about this approach is that it acknowledges there is no fixed “minimum” standard. Having the library data good enough to get the job done is not good enough tomorrow when you need different parts information from the library. And then just when you think you have all the information about all the parts you’ll ever need someone will invent some more or want some more data associated with the existing ones or you will get a new product line. The concept of attaining a minimum doesn’t sit easily with the goal of reaching the best quality. 

Hurrah for the librarians. They contribute enormously to make the designs perfect.

 From time to time it looks like too much. All those things you should just know about CHS can be a little bit daunting.  But you join the little pieces of knowledge with the bigger ones until you become an expert. One of the customers I deal with has staff who guide designs all the way from concept and architectural studies, through systems design in detailed optioned logical drawing to Capital Integrator topology views merged with Mechanical CAD data and on to harness BOM detailing. Oh, and electrical simulation too. Oh and I haven’t really made it clear. That’s the same person covering all of that ground. Many electrical design processes instead fix and compartmentalize these individual functions.

Interdependence in interdisciplinary flexible teams is a common. It is rare to see a single individual having end-to end responsibility for a design. If you operate in a work group, the more you know about the requirements of people working upstream and depending on you downstream; the better overall efficiency is acheived. The less you know of the full requirements, the more chance of miscommunication in the hand off between one person and another. 

 My own job is more collaborative in nature rather than having sole responsibility for things. I’m part of a multi-disciplinary team of programmers, product architects, managers, quality assurance, customer support and training professionals. I rely on them, they rely on me.   

Here’s my recent experience with “things you just ought to know.”

On October 7^th I got an email from a colleague sharing a little piece of information about CHS. Where you run in CHS the  process to synchronize design data to a set of  harness designs a.k.a.  “build list”  you get a dialog shown below.  

Pass data from wiring diagrams to harness drawings

So another one of the things already I “just knew” is that since this dialog was introduced into CHS to select an available source design (topology integration) or set of source designs (wiring diagrams) you double click the check boxes on the left of the window and you single click the ones on the right. Just one of those things eh? I had been caught out waiting for half a minute for something that wasn’t going to happen the first time I went in to learn how to use this little piece of CHS Harness XC. 

 

My colleague informed the rest of the workgroup and I of  a little feature that has yet to find its way into the help file. Use the “Control” and letter “A” on the keyboard and that will allow you, where you are following the wiring diagram-led design flow to select all the designs on the left portion of the dialog.  A small time-saver.  

 

 Fast forward to November 23^rd  with a coworker from Mentor Graphics customer support   looking together on a Web co-pilot session at an issue with some data troubling a customer. Sometimes there are many dozens of wiring harnesses in a form of transport. How about a cargo transporter aeroplane for example? Or an eighteen wheel truck?  In our investigation we wanted to define a build list with every harness family named in it.

 

Defining harness build list in Capital Harness XC Ctrl-A selects all

The CHS graphical user interface (GUI) consists of a common set of programming objects.  So one of things I tried, knowing that “Control and A” worked in similar circumstances was to do the same thing in the build list manager interface. I knew it worked in the synchronize harness design dialog, and in many other places in the software.

What I was aiming to do was to set up for the first time a set of harnesses in a build list in order to synchronize them for the first time. For an entire car that was twenty-one composite harness family references to include.  

 Did “Control” and “A” work for me? Yes it did and it saved me perhaps 4 minutes.

 Small idiosyncracies and inconsistencies are almost inevitable in a large software system.  I have pointed out in the past when training customers, a trainee may be going to see more of CHS running on their computer day-to-day over the next few weeks than of your husband/wife/partner/significant other/domestic loved ones. Certainly that is what your managers hope when they send you to training.

 You spend time with a piece of software untill you know all the little ways and most of the tips and tricks – get  bonded with it. The observation about time spent with loved ones doesn’t hold exactly of course – analogies often don’t. I’m not suggesting that you should love CHS unconditionally and buy it a nice birthday present.

 Here’s what customers using CHS do to know more than they thought possible:

• Work as a team – the whole is greater than the sum of the parts. Worflow management in a modern complex organization is collaborative – everyone relies on everyone else – find out how and pay attention to the group dynamics.
• Learn from mistakes and inefficiencies and adapt. Ignorance is no defense in engineering.  Allow learning to come from what has gone not so good. Permit people to work out positive lessons learned and pass the lessons around to stop others going there.
• Participate in improving the documentation steadily over time – help files, technical bulletins, add resources and techniques like the Mentor Graphics communities. In Mentor Graphics we put time and effort into these areas. It is a shame to let that opportunity for learning pass by. Customers often develop their own “in-house” written material around their design process. Intranet, E-rooms, SharePoint and Wikis. Sometimes Mentor Consulting is hired to help out. Get yourself immersed in and particpate in documentation activity. When you can teach other people a subject it is the confirmation you know it thoroughly yourself.
• Push the boundaries. It is helpful to have access to a safe area, a “sand pit” where you can experiment without risk of inadvertently changing production data. This software reflects the complexity of the design tasks it accelerates. It is good to have a neutral zone containing a known set of data to “try it out first.” Be experimental in a safe environment.
• Share information with each other. I am fortunate that my coworkers are exceedingly generous with their time when they come across something interesting in noting it down and circulating their findinging amongst the workgroup. This saves the entire group a tremendous amount of time in the long run. 5 minutes here, 10 minutes there multiplied by 20 people over three years is really worth having. Reciprocate and initiate information sharing generously.
• Extrapolate and deduce from what you already know. Prior knowledge generally is predictive of how things operate elsewhere in the same system. Exceptions are nothing more than that – exceptions. Be optimistic, things are usually going to be the same as what you already know in the software.

There you have it. You can know more than you ever thought possible. You can extend your brain power. The good news is that it is a social and friendly activity, not a thankless solitary experience to improve your intelligence.

Am I saying CHS makes you smart ? It may seem a lit like that – but of course not. You were smart before you ever saw CHS.

I highlighted the powerful influence of customer lbrarians in delivering automation in the design of electrical systems’ interconnects using the capital suite of programs. Librarians get proficient initially through the ministrations of a trainer to guide them through the concepts of the software and how these apply to their working lives. I’ve also singled out the product management staff who convert their professional expertise and their personal understanding of users’ and marketplace needs into finished product. This group of people brings the new modules (e.g. Capital Architect and Capital Modular XC) into being. Afterwards it is work of the Educational Services Group of Mentor to author a training course.  Trainers have a challenging job and it is really well done.

And there are a lot of courses in the repertoire http://www.mentor.com/training_and_services/training/courses/cabling_and_harness/

The trainer who is going to deliver the course as a paid-for service is usually the main author, sometimes the only author. If that were all the accomplishment a person has to show for their working life “I wrote a training course or two) I think we should be quietly impressed. Distilling the countless features and the multiple patterns of use into ones which are highly relevant to the majority of users and interesting and instructive to the others for whom the task is only indirectly part of their role – that takes expertise and experience. Gathering it into a coherent package, trialling it, maintaining it is the ordinary part of the task of writing a training session. The real magic is in constructing something which has the potential to engage the audience.  Someone writing a training course is providing the potential for inquisitiveness to turn into professional effectiveness. The person delivering the training course has the goal of  realizing that potential from curiosity through to knowledge for the benefit of the customer and not for their own self-satisfaction. The Mentor trainers are great teachers who provide the environment in which the talents of the trainees can really shine.

Capital Harness XC - student workbook contents to show the comprehensive curriculum offered for one of the capital applications.

The participants in training courses come from a variety of cultural backgrounds. This is an interesting and stimulating fact of the business life for the trainers. I think it is good to acknowledge that their skills are not confined to international borders – which means their professional lives take them travelling as much as any sales or technical marketing person in the software industry. Perhaps more. And part of their job is to inspire more people, to aid understanding for people to whom English is a second language. To switch etiquette from the Asia Pacific deference to the European relaxed respect.  Sensitivity to the needs of students whether Middle Eastern, Brazillian or German for example is really important so that the training is optimally effective.

A tough audience here! Mentor Graphics Application Engineers brought their baggage, personalities and cultural heritage from many countries of the world and an interest in heckling the trainer.

A comprehensive mastery of the subject matter is a given, but there is actually a lot more to the remarkable skills of the trainers. In teaching something to adults, you are negotiating through the aspirations for success, the eager embrace of change through to the cynical and suspicious attitudes of people who don’t think the automation can fit their bsuiness process. There are as many motivations and likes and dislikes of people to the way in which they learn as they are people. Some students fold their arms and say “show me” and the person on the next computer may be skipping three exercises ahead and trying their best to make the software crash. You have to have a serious talent for communicating and a gift for listening as well as a gift for being listened to to have this job to flourish.  A good human beats a remote scripted session guide in mist categories.

Luckily we have some. Hip Hip hurrah for the trainers!

In an internal meeting at the end of last month I heard a fact announced.  In the total worldwide licenses for Mentor Graphics’ software for Integrated Electrical Systems the balance has changed. There are now more Capital Harness XC seats than Capital H Classic. The legacy system, the last generation software is gradually replaced by the new.  We are now at that stage where the front runner has been caught. CapH Classic was something I first saw used in production in 1997. For Harness XC to overtake it in number of user licenses in the time it did is impressive. From zero to parity in numbers is the same trajectory too for VeSys 2.0 replacing previous generation installations of VeSys Electrical Series.

Stability with VeSys Electrical Series and Capital H

On an individual level, many customers face decisions about challenging the old, the tried and trusted.  I think it is interesting to see what is involved in deciding whether your current tools compared to a new alternative shows obsolescence rather than value.   

So when do you upgrade in the near future, for example from VeSys Electrical Series to VeSys 2.0? When do you let go of years of good results, and look forward to years of better results?  The answer seems to be different for each customer.

Show and tell.

Business is fundamentally about profit, so my advice is follow the money for the evidence of when it is time to change. And here are some clues where to find the money – starting with where it usually isn’t hidden.

We have some money to spend … what can we buy?

•  A decision to change is almost never in my experience attributed to initiatives and future-proofing (we are working ahead of our competitors and investing as a result of R&D effort).  Very rarely have I seen an influx capital for modernization purposes result in a shopping expedition including cabling and harness software tools.  

I like the "slide rule" controls. The old technology nods to the older.

Why are we paying this money for old things?

• There are signs you cannot support the old technologies … when sunk costs are memories and continuing support of proprietary CAD engines are rising or stable but there is little perceived value in them. What do we get for this mainframe maintenance?  Old staff who knew what to do (the corporate know-how) have moved on and younger employees who want to work with more cutting edge tools, modern user interfaces. Sometimes you begin to have quality problems because the old tools assist you in elevating quality but did not automate the building in of quality into your product and the new hires are making expensive mistakes which you thought you had eliminated years ago.  

The status quo can cost dearly.

• As well as the melodrama of “return of the misbuild” the design to manufacturing throughput possible with your current tools may look like a steady jog rather than an exhilarating sprint.  Perhaps also managing  product complexity  is troubling you. Potentially you can have millions of option combinations are getting ahead of your tool and your people’s ability to cope. There’s are warning signs of a lot of money being spent on human validation steps, a lot of time being lost to eliminating errors. You suspect at first then are certain that you need something which will crunch more data much quicker and be much smarter about how that is done.
• And on top of the profit-goal business drivers, there are the increasing cost-of-doing business demands, for legislation and society evolves alongside your customer requirements and you find your resources doing “where used” & “what if” and hand-checking for recyclable, lead-free, withdrawn components. Another example of having to run faster to stand still in the market is to have to respond to warranty claims and recalls and you wish there is a better way of automating these things.  Perhaps with some updated software you think?  

The Vendor is pushing the new tools for some reason – I wonder why?  

• You are in a commercial partnership, or seeking one I hope with your supplier of enterprise tools. Does your vendor even have the latest stuff ready? What’s the view of your trusted contacts at your supplier?  Does your vendor allow the sales person to offer incentives the more easily for you to adopt the latest version?   

Advantage to incumbent supplier: 

• Your existing vendor offering the next generation of tools as an upgrade is a welcome suitor for your business generally.  You don’t have to be concerned so much as with a new vendor who may not understand the customizations, configuration and sometimes undocumented usage of the current solution. The vendor ought to have experience which is directly useful to you in transitioning to the next generation of tools.  

Cost of moving from the status quo is not zero either – so you better plan.  

• Is the migration path to the next generation an investment in time, training and other resources you can contemplate, something you have budgeted for? Changing over will take effort. Somebody somewhere surely has to do some work sometime even with modern impressive IT magic.  But cheer up, you are not going into a project to refresh your workgroup to get back the same level of efficiency, you are investing for a long term significant return because your team will be working at a higher efficiency.  

 General, indirectly financial motivations for moving to the next generation.

 I think we can refer to this for short as the 7-ish year itch?

• I have previously classified underlying requirements for software capabilities to fit your needs previously as  D) integration with other corporate systems,  C) produce the CAD outputs  e.g. prints   A) model your product intricacies and your design process and B) provide business value and return on investment.  Those are fixed needs every customer has. If your present tool set is letting you down on even one of these categories you have to act or have a high tolerance for business inefficiency.
• Tactical level requirements – if you already have something which has for some time been sufficient to your needs as described above  – are what you are going to notice. These are what are going to give you a competitive advantage, a better best practice than your rivals or comparable workgroups. If you keep up to date with the best in class tool capabilities or can recognize useful technology  when you see it, after about 7-8 years from your last deployment of tools and new methodologies in your organization there will be indications that the leading offerings in the market are different to what you are using.

The meantime since you last bought tools in the market, the tastes and techniques, approaches and technologies have changed.  In the VeSys Electrical Series and CapH Classic to VeSys 2.0 and Capital context the transition from flat-file and CAD engine moved to data-centered fully integrated graphical tools separating content from how that content is represented has happened. XML files are moved back and forth in a change management environment rather than import/export of structured and semi-structured text files for example. Similarly, another example is that drawing symbols are inside a database and under librarian control rather than external to the application lying on a file system folder.  You go for these advances not because you are a geek, but because they offer real, measurable benefits to your business/your customers. Better design change control, the promise of heightened quality.

Click on the picture for a bigger version.

After you follow the money, eventually you chase it down and catch up with it. 

All you have to do is capture the business case, the extra money you will save in efficiency. Shorter diagram development time, shorter wait times for processing, fewer corrections,  less time drafting,  built-in analysis and quality checks.

A well-run meeting is inspiring and fleeting.

Mentor Graphics internal meetings are usually jam-packed with facts. I wasn’t alleging the opposite . This particular fact that the number of Capital Harness XC licenses now being equal to Capital H Classic licenses intrigued me. Interesting where paying attention in meetings can lead you. I think more I should do it more often. Follow through from where the facts have originated.  Obviously I cannot pay more attention than I already do in all these meetings.  

Hope you found where the the musing led me useful. Comments and disputation very welcome as ever.

A community of practice is a way of organizing in a specialized field so people with the same interests can broaden their professional knowledge, learn and interact with others. Web technologies in the last 10-15 years have greatly extended the opportunities millions of people have to network, participate and experience professional growth. Capital and VeSys have gone there too and have a well established site

The way we give now.

For the Capital and VeSys product families Mentor Graphics through the IESD (Integrated Electrical Services Division) organization started some time ago a Web community presence, which is open to any registrant customer with a support contract running for their company. You can register under a pseudonym if that makes you more comfortable (so your competitors don’t get to see the competitive advantage your have in the tool). This has been a resource for customers for over 4 years, it is mature and well thought of.

One of the key advantages to customers using the Electrical System Design and Harness Engineering community is that the Capital and VeSys Product Managers are expected to check frequently for topics and contributions in their area. If you wonder what it is a software vendor’s “Product Manager” does and what’s in it for you – I wrote a post here  https://blogs.mentor.com/paul_johnston/blog/2010/02/15/latent-hero-series-277-the-product-manager/  explaining why these people are your friends. Like most of us, these people are busy, so email alerts are provided for them – the subject line of new posts will be presented in alerts and the emails are predicated also on tags assigned to posting. So here’s the first tip, construct a good title if you are posting, and make generous use of tags.   Mentor’s responses in these communities are moderated, managed and and tracked. Generally the monitors are happy with the speed of responses, and they believe that making this “behind the scenes” expertise available kind of directly to customers carries a lot of benefit.

In a sub-branch of the Mentor IESD Community site, these are shown as the popular tags for content and are linked to the postings.

There’s not a service level agreement stopwatch running on answering questions or responding, in this informal environment there is no undertaking to respond within “x” hours to any question. But as well as the development people there are also the worldwide practice of Consultants, Customer Support engineers, and the field application engineers attached to the sales force reviewing this community of practice. Here in Mentor Graphics we feel that this hang-out is beyond a critical mass of participants, and the organism “just ticks over by itself” in the words of one custodian.

What it looks like to be in a Community of Practice for Capital software.

 Types of Participation in the Community of Practitioners

For some communities of practice revolving around software the most active contributors may be skewed to the customer side rather than the vendor side. This happens sometimes because it is a simpler product in which it is easy to become an expert “front-to-back” and then share your enthusiasm and interests with other people.  With Capital, deployed workflows tend to be unique to customers so that your customer experience is not guaranteed to be transferrable to another workplace in whole, though certainly in large part it will be. I know this because I have seen people work for different customers re-using their knowledge of best tool practice.

Most of us who speak regularly with users of Capital get the impression there is a positive reaction to the Community site.  Analytics can be done with a site like this and there are around 200 customer users with an upward trend on the IESD site I am told. More are welcome, each new registrant will find something to interest them.

The 3 most popular areas of the Community of Practice site:

1. Electrical Design through to Harness Manufacturing Process including Electrical Analysis  – For practitioner issues in the core workflows of customers

2. Integration area  –  For plug-in  code downloads using the Application Programming Interface (API) of Capital.

3. General Discussion  – this is where people start off posting documents and asking questions when the category is uncertain

An area where there are proportionally more customer staff active than their representation at large in the community is in API work. This makes sense because programmers are much more used in their daily work to reaching out and collaborating to arrive at potential solutions for technical challenges they have.

Proportional distribution by main functional area over 150 Example Plug-in for functional area. Ratio approx.. 7:4:4 showing a bias in favor of Generative Flow and Capital Integrator assistance.

The more technical the area – we can infer, the more useful you as a user are likely to find the community spirit helpful.

Getting Started and getting benefit – joining the community.  

On http://communities.mentor.com/mgcx/community/harness?view=overview   – the communities site there is a really good search facility so you can find readily all material on a particular topic of interest to you. Most people who join spend some time finding their way around before progressing to making their own posting. If you are feeling bold don’t be inhibited –  plunge straight into debates and open discussion threads. You can choose to register and interact under a pseudonym so that competitor companies who may also be using the Capital or VeSys software cannot identify your activity or topics of interest and work out how you are deriving competitive advantage out of using the Mentor Graphics software

A typical starter use case for a customer joining Mentor Communities for Integrated Electrical Systems Design is to pose a question where Customer Support isn’t a place you would expect an answer. That’s why there are so many “How To” postings on the site. In fact, the answer to the question you have may already be out there – so search before you post is usually a good idea.

Worth your time

For new and upcoming customers I make a point of mentioning the Community as an additional resource in Mentor’s good reputation for supporting Capital and VeSys. It is your direct line to the experts, plus a searchable library of resources of best practices and advice, concept guides and approximately 150 plugin examples (and growing) examples being a drawing Part ID table and advanced design compare.  You can post a question and you can answer a question – both give and receive advice as a practitioner of Capital or VeSys.

What next after you first join – types of interaction?

The key challenge for the future is to keep the site content relevant to user experience and foster participation by satisfying personal customer goals for interacting and on a collective level meeting the community need. We see at Mentor customers who have the Capital software being deeply ingrained in their business processes and that is when the community participants go “deep” in their interaction and share their advice with other practicioners. We notice these because they seem to show us what we always thought would happen: the software let out in the world would be liked just as much as we like it!

We at Mentor also need to get disciplined to go a little against our human natures and also remember to be inspired by the most frequent customer interactions to the Communities site, where there is a steady stream of readers coming to the library of best practice documentation. It is a place where it is perfectly ok to be a consumer of the material. It is more than ok. Providing a place to access useful information and interact with experts and other customers is one of the main goals. Libraries are quiet places. You don’t have to interact with experts, it is not compulsory, reading the material and satisfying your need for a deeper understanding of the practical ways in which Capital software can deliver value to your business situation may be enough.

Relative size of Library held in the Community - Excluding plug-ins (250 best practice documents and growing)

Getting more involved, giving something back to the group.

Beyond a mode of participation consuming the collective knowledge, there are some easy ways to participate actively in small ways and do it very fast and conveniently. You can rate the documents and code examples you download and read. You can leave a short note providing feedback. And you can ask questions, have the moderators and seasoned posters to the community transfer some of their knowledge to a specific purpose. It is good to do this, it encourages your fellow members, and fosters further interaction.

The way it works with most community members is that after a time period where they read material and become connected with the community, you become comfortable with the idea of posting original material which you have created which return the favor to the community for the help you got.

I don’t know culturally whether this will make sense to some of the Capital users from different parts of the world, but the process is a lot like becoming a “Pub Regular” – you don’t ask to be part of the atmosphere of the bar, don’t follow a set series of tasks, you don’t have to pass any entrance exam, but after a while it is your Pub and you are part of the scenery there and you are a “Regular.”  Pretty soon new visitors to the community will be looking to you for advice and pointers about things you know through and through.

In the future there may be different ways come into the Community to foster inclusion and participation, possibly around some special events being organized. It will continue to be a valuable and growing archive of expertise, receptive to new ideas and new discussions, convivial and polite, open into the night hours – people visiting all the time, some staying for just a few minutes, others relaxing into the ambiance of the place, some approachable, some aloof – some garrulous and some politely declining to enter into lengthy interactions. Yes, definitely a bit like the village pub.

Rolling out an enterprise system is for many Capital electrical platform design software customers a multi-stage process. One set of tasks in managing the distribution of the value to individuals and the corporation is to integrate to the corporate IT infrastructure. This is done mindful of the needs to provide acceptable reponse to users, adequate security policy conformance, appropriate data backup strategies need to be in place, confidence in up time or availability for production users, provision of a trials/training environment.

Make management of the Capital IT infrastructure look effortless.

Actually that is just the highlights list of user expectations. There are many many more tasks in IT management to deliver a solid Capital application to users at multiple workstations – probably on multiple physical sites and probably in multiple countries on different continents. Systems and wiring design and manufacturing is a global business, so the software that supports that business is also by necessity architected to be used worldwide in diverse computer infrastructures.  The technologies of a military aerospace customer running Capital can be radically different from Mentor’s Educational Services’ virtual machine drop-in and go systems and data configurations for example.  But in all cases a common need, and usually the first one articulated amounts to ‘the software must be quick enough”  – no lags, no delays, no hiccups, stutters, freezes or lengthy waits.

That brings me to reveal what the  “P” word is. Performance.  My inclination has always been to taboo the word in meetings, and to have clients and colleagues find another way of describing their aspirations, and observations. Because in “performance” it is all too easy to chat about acceptable/unacceptable without the discipline of measurement. And then people become entrenched or adamant in their opinions rather than working on the basis of fact. Complaints are good, because knowing what you are unhappy about is the first step towards being happy. And the path to being happy about response time of a software application is knowing the timings. First the baseline or control  timing, second the same operation as you find it with a changed piece of the environment e.g. a workstation in Argentina and the same specification equipment in Poland.  You may be surprised at how many debates about the speed of software begin without reference to any standard measurements.

Timing tests with representative data are good ways to understand how your system is behaving. Harness XC processing is a common benchmark choice.

Of course our brilliant programmers and development experts designed a superfast code base! I can promise you it is very rare that any downturn in some processing speed is attributable, proved to be caused by inefficient logic in programming. Very rare over the last six years. So should be very rare over the next six years because Capital has a stable code base. Think about it, how likely is it that a programmer would write a clever routine to wake up after six months on a given version, yawn and stretch, take a look at the user base, see who is logged on with a Poilsh name and make their database inquiries run twice as slow as their Argentinian coworkers doing the same work.

Fortunately over the life of Capital there has evolved a body of knowledge amongst the Mentor Graphics staff who support customers’ deployments not just how to handle issues like these, but how to help customers devise a set of timing tests representative of the loads expected, and usage patterns specific to their needs. What’s going to be important to you rather than another company can be advised by the Mentor Consulting experts (intensive paid-for engagement and value-add)  the Application Engineer assigned to you  (best practice advice tending to specifics for your particular circumstances)  or via the Customer Support Engineers (responding to service requests with highly specific answers).   These people can help you avoid puzzlement and preplexity when someone comes to you with the general malaise “it’s too slow” and help you ground the problem definition in the real world, and give you practical steps to removing the measurable issues.

Useful helpers.

So what sort of operations are representative for most customers? What you shoud look at is not a big list of things when you are identifying a set of normal benchmark timings against which future measurements can compare (new hardware/ new software versions – amended WAN configurations etc.). The right P-word here is “Plan” – have a plan to measure these regularly.  Tracking these via a simple spreadsheet is commonplace – be sure to publicize the results widely so stakeholders know there is someone watching over this aspect of gettign return for the business from the software. It certainly does not have to be a lengthy list – but the more coverage the better the insurance!

Simple metrics like the time to retun an answer from a part selection dialog in Capital Design like this one are all you need to put the debate about response time in the Capital application on a scientific footing

You cannot manage what you can’t measure.

• Data Crunching through Capital Manager and back to the database repository and its manager: significant processing options performed frequently – Harnesss Processing in Harness XC for example on a small, a medium and a large example of your product data or a representative approximation thereof.
• Pulling Data Across the network: open and close and save tasks on your designs (e.g. schematics topology designs, formboard drawings) – the most common things which your users will do  – so any change in these timings will be noticed first by the user community. Include logging in to the system in these tests. This exercises the parts of the system where data is buffered up for local client work.
• Common editing and design operations. Interrogation of the library items (devices & other parts definitions and symbols) once you have opened the designs. This tells you what the normal user experience is going to be as they work day-to-day.
• Passing on data from the Capital application to other parts of your IT environment: Perforn some popular print or reporting functions.
• Capital data exchange: Import and export of project information – although this is a rare occurrence these operations are probably the highest “stress” you can present to the system. Keep a data set constructed just for this purpose if you can.

Whether the list of tests contains multi-user weighted tests, accumulates results from different sites is often up for grabs. Your decision whether you want to go deeper and look for comprehensive results or settle for an acceptable minimum.

My view is that the user community will thank you for depth and attention to detail. And you will thank yourself for anchoring any performance discussion in reality by providing factual, observable data.

Capital software covers the automotive electrical design process from early conceptual architectural design through product engineering. And onwards too through manufacturing engineering to manufacturing assembly. In this entirety one would expect sophistication is needed the ability to handle complexities, nuances and variations. Doing this while sustaining a user-friendly reputation has to be achieved to keep users happy.

 What do you want?

Finding your way around functionally rich software takes a combination of knowledge and inclinations. There are lots of methods writers of software utilize to make that journey from first impression to lasting familiarity a smooth transition. A focus aspect of the design of computer systems is known by the acronym HCI – Human Computer Interaction. To most consumers of an application – you are more interested in the benefits of using the system rather than how clever the system is in terms of how it interacts with you. Your judgment of whether software is good or not is quite rightly not usually a conscious one – you should not have to debate the issue. Can I get my job done and is the experience one where it is easy to do so?

Visualization.

When you are designing a transportation platform, there can be hundreds of signals, thousands of wires, hundreds of wire harness part variances, oodles of options, dozens of Electronic Control Units, a smattering of ground paths, a maelstrom of engineering changes to many scores of diagrams. It helps that you can pick out the things that you want to concentrate on quickly. In software applications – if visual cues are not obviously different it will be difficult to distinguish between things you as a user really do need to discriminate between. In Electrical platform engineering the visuals – the release prints are really important. Those pictures are summaries of many thousands of words.

Hence when drawing standards are being decided, your company may choose to identify wires for power and ground by different and obviously distinctive colors on the schematic. Furthermore when drafting or generating service and technical publications diagrams using Capital Publisher you can see a case in legibility and accessibility for rendering these schematics showing the jacket cover of the wires in the pathways of the wires across the diagrams.

Conductivity pathways are more prominent if shown in different appearances.

Another example of reducing the ability to misinterpret your data as visualized on the electrical diagrams is the technique of tabooing names or elements of names which have potential to confuse. So, for instance it is common to have letter “O” disallowed in reference to wire naming, or naming of other objects such as devices, harness mechanical items or cavity names. This obviates the confusion between zero (0) and (o or O). Similarly Z, z, I (upper case i), l (lower case L) are frequently not included in permitted names in order to avoid confusion with numerals 2 and 1. B may avoided because of similarity to 8. You pay attention to detail in the textual data you use.

Lookup lists in Capital – Project resources and rules and constraints.

This is part of the “prevention not cure” philosophy which leads one to favor creation of permitted lists of device, connector or harness family names – or leads to the applying of rules so that you must have the revision suffixes of your designs and diagrams – your child harness parts for example – correct by construction. It is best that there shall never be a hint of a question of a doubt in your mind about whether that is a dash or an underscore in the harness part number. And there will not be any room for doubt, nor a need to check if one or other or both are by rule excluded. That’s what correct by construction means and how quality improvements delivered.

The Capital User interface (and VeSys 2 too for that matter) has a multiplicity of these features. There are also some other really good practices for showing what you want to see (fade in and out of manufacturing process sub-assembly/module views in Capital MPM/TVM for example. Additionally highlighting of pathways, highlighting during for simulation, the trusty zoom to, a one-key open associated of sheets – all fast techniques of getting to your required sub-set of data quickly.

New things added in new versions – old stalwarts still serving you well.

My favorite recent addition was last year’s introduction of “show circuit” in Capital Integrator – an implementation of the Capital AutoView technology which came out of users’ welcoming response to a similar “show-me” rendering feature in Capital Publisher.

Cutting down on the amount of available information – de-cluttering – is for a lot of engineers an important aspect of being efficient. Just enough information is best. Too much will increase the risk of ignoring something significant. That’s why the Design Rule Checks provided as standard can be pruned back using Capital Project so not all of them run, or run and give indications action is imperative. And when you are examining with the output you can yet further filter to better prioritize your response and understand the importance of the feedback you are getting.

The display of Design Rule Validations for a schematic can be dynamically changed as you filter the list to concentrate on the important ones to you

Consistency of the “look and feel” and the detail of how you interact with the data sets has also also achieved through the different functional modules of Capital. You can expect to see the same Part Selection Dialog in Capital Harness Manufacturing Process Management as you use in Capital Logic for example. This means that wherever possible the short-cut keys, the print dialogs invocations are standardized and the benefit is that if your people have responsibilities which cut across traditional design cycle boundaries (the harness person is encouraged to explore the systems designs) there is a minimal training overhead – perhaps none in some cases.

Take a test for which there is no pass mark.

It has been remarked by a colleague recently that my approach to using Capital is to concentrate more than average on using the right mouse button, and in terms of keyboard entry I find my way around via the tree view filter a little more than most other users do on average. Also I use the ALT- key combinations to invoke functions more than most. So as an experiment – given that I am less inclined to make use of toolbars, I took a toolbar for adding diagram objects into a schematic from Capital Design and pasted it into a blank page and tested myself as to whether I could “run the table” of getting the function of each of the icons.

16 of many functions collected in a toolbar. In the Capital Logic application you can simply rest your cursor over the item and be told what it is by a call-out message

Bear in mind I am an expert at this so I should do pretty well you would think. So out of sixteen, I guessed correctly thirteen. If you are trying this for yourself and bagged a superior count, well done for your achievement if you had more than me – and for reasons explained later, well done if you had fewer correctly identified than I.

The item furthest to the right is the icon for adding graphical elements like lines, circles and other shapes to the drawing. It was the three to the left of that which I gave up on being able even to guess at. The drafting purpose of those icons are actually: to add overbraid; edit/add assembly; and finally to make/modify a block.

Now comes my excuse for getting some wrong. Not that the assembly icon (looks to me anyway) like a blue audio cassette from late 1970’s. Nor either shall I complain that for some simple picture of an already abstract concept – like one of those I got wrong was add a block – it is difficult to get an effective further abstraction of an already abstracted concept. There’s only so much help a picture can give you. Try designing an icon denoting phenomenology and you’ll see what I mean.

Mix tape not icon

No – here’s my excuse – those three are ones that I seldom use. Most of the work supporting customers is done where blocks, over-braid definitions and assembly items are not used. Icons are as much memory aids. Not for initial cognition but re-cognition. That’s my excuse and if you only have a few out of sixteen correct then I guess you don’t draw schematics with Capital Logic much at all. When you do get habituated to abstractions – it doesn’t take long to adapt to EEEEE’s of UUUU’s conventions – you’ll do well or better than I did.

Answers to the test

Here are my answers so you can check your own if you want to play along. I allowed myself 3 seconds only for each answer – any longer indicates a greatly reduced chance of guessing right. And there are no prizes for beating me, other than the glow of satisfaction knowing you did better than someone who may be supposed to know all 16 via subliminal fanaticism.

• Make parameterized device & characterize pins later
• Insert plug
• Insert inline
• Insert receptacle
• Ring terminal
• Add splice
• Add net conductor
• Add wire
• Add highway
• Add shield termination
• Daisy chain something … hmm multicore shields phew got it.
• Make multicore
• Don’t know (overbraid)
• Don’t know (assemblies)
• Don’t know (add/edit block)
• Draw graphic shape with no electrical content/meaning

“We certainly want your ideas and our goal is reply, enrich and decide on what we should do with any idea as soon as possible. This does not mean that we are going to implement every idea, that is not possible for a number of reasons but mainly due to resource and our desire to ensure that we are answering our customers’ principal business needs 1st.”

This is a quote from Andy Reilly, Product Marketing Manager, IESD  – from the IDEAS website.

In this final piece in the mini-series, I will review how to give your proposals for enhancing Capital the best chance of success, from an insider’s point of view.

The Numbers Game of Enhancement Requests.

Assume this about your requests plus everyone else’s: few will make it into the software. Exactly how many, what proportion reach delivery varies. Contrast enterprise class PLM and 3D CAD systems and some specialist commercial software for packaging inventory you bought from a small company and you are their first major customer.

Of course your enhancement requests are different. They are better thought out, more brilliant, more attractive and more intelligent. Nobody can argue you don’t have a close affinity for them.

In reality you need to make your initiatives inspiring to others, and clear frontrunners to extend already extensive software functionality of Capital. Requirements drive software features and software features get added into Capital at every major release. That means lots of new functions and features. Not to participate in the Mentor Ideas way of recording your requirements means you are choosing not to have your voice heard. You are letting other people represent your interest.

These following numbers aren’t the true ones – I offer them as a lesson in expectations. Let’s assume that on average six enhancements a week are being added by new users around the world and history shows two per week will be taken out of the pool and actioned. This leaves four, or which 3 are not going to make it into the software and one a week is classified as unsuitable – perhaps because the software already does what is requested, or it is a duplicate or a very close neighbor of an existing proposal already in the system consolidated into the prior.

Formal Stages of an Enhancement Request for Capital as described on the Mentor Ideas Website

Face the truth: Take Comfort that I wasn’t rejected, I was simply not accepted.

Occasionally an enhancement gets classified “out of scope” which means it may be an idea, but it is not an enhancement. It has happened to one I sponsored – something which was supposed to be designed into the software which wasn’t realized properly and was fixed . Another out of scope reason is that Application Programming Interface (API) provided in Capital delivers the function.

Like most software producing organizations, IESD does not consider the un-met enhancement requests backlog. There is not an intention to do everything requested. There isn’t infinite resources and volition to do so. This is for many reasons, for example extending to new functional areas rather than enriching an already acceptable function set of a stable product is the preference.

Who cares about measurements?

If you care enough you can put numbers into the benefits from having a future improvement – things like time saved, quality issues eliminated etc. In first in this mini-series of postings I have offered a few pointers to Capital customers how to present their requests more powerfully and persuasively. Well constructed proposals have better chances of appearing in a future release. If you prove to yourself with fact finding and metrics that your thoughts about how software functionality could be extended actually does translate to tangible benefits to your organization you prove also it is worth upgrading swiftly to a later version of Capital.

Mentor Graphics cares too. Product Managers  are responsible for the overall product quality and attractiveness to potential and actual users. From the other side of the customer-vendor relationship they are also working from facts where they can, and opinions where they cannot.  A description of the type is here https://blogs.mentor.com/paul_johnston/blog/2010/02/15/latent-hero-series-277-the-product-manager/  Tap into their concerns and motivations.

One area it is difficult to establish metrics for is for is the uptake of enhancements. As a matter of course customer initiators of new features coming into the software get notification when the new release is imminent. How soon newly introduced enhancements get into productive use at customers is a different story. See https://blogs.mentor.com/paul_johnston/blog/2014/05/12/why-would-you-not-want-to-use-the-latest-capital-software/ for motives to go to later versions.

When you see an enhancement requests you have nurtured coming into the software remember to close the feedback loop with Mentor Graphics. Let us know you have adjusted how you work for a new feature and report whether the expected benefits were realized, or exceeded.

The value of user activism in promoting your agenda.

There is a very simple method used by the Mentor Graphics organization understand what a customer’s business needs are. It is called listening. To listen is an often overlooked form of interaction. Engage with the Mentor Graphics contacts you know to explain things to them. Go to the trade shows, the IESF conferences, User to User meetings. One of the benefits of accepting any Customer Advisory Board or Group invites is that you will be participating in a good platform for collective representation which emphasizes your enhancement requests.

Advocates – the many and the few.

A collective voice amplifies your case. To enlist the support of powerful individual voices and brains can help also.When Mentor product managers attend Customer Advisory Boards, IESF seminars and User to User meetings a unified message from a set of users is intensely memorable. Experiences where users interests are represented in groups sticks in the minds of Mentor Graphics product development managers.

There is also a lot of good that can be obtained from utilizing Executive- to-Executive level contacts to promote a desire to have an enhancement included in a future release. A message conveyed at senior management levels across from customer to vendor can do much to accelerate the consideration of an enhancement.

If you are considering elevating the message to high-level meetings of course it is a tactic which needs you to be comfortable that the subject of the enhancement request truly is significant and substantial. Neither you nor your software vendor wants to promote a new feature which has disappointing up-take or yields marginal improvements. An executive sponsor may hold you to account for your advocacy of something which had a poor return.

Elevated presenting of the requirement at an upper management meeting should not short-cut the technical evaluation and validations needed in the software development process to deliver a quality end product. Remember that fully justifiedideas give you a better chance of getting them accepted. That still holds even if you have a figurehead manager who will take a headline description of an enhancement you want and champion the idea with all vigor. By the time it gets to Product Management and Development Engineers to turn this request into software code the detail must be present.

Vary your tactics to promote different categories of enhancement – getting to be first amongst unequals.

It may be apparent to you already – in case it isn’t – enhancements are not all equal. Enhancement requests are different types from different pressures on customers at different stages in the lifecycle of adopting Capital. There are different typse of user who collate and records requests. Typically the users who make and promote these requests are expert users, who spend a lot of time using the tool and particularly the system administration parts of Capital. Therefore there are proportionally more Capital Project, User and Library and Integration Services requests than there are users of these modules e.g. compared to Capital Logic, Capital Harness XC.

The vetting, acceptance and delivery of enhancements is not a process where “all things being equal” is a phrase that makes sense. Giving your proposals the best chance of making it through the process starts with recognizing this and deciding you will do things to make your enhancement ideas more prominent and compelling.

1.      Upgrade type enhancements linked to the user environment beyond Capital.

A type producing numerous requests is to address environment support and compatibility issues. An example is a call for Chrome version “X” with Java Run-Time engine “Y” to be supported by Capital Publisher smartclients. Also included compatibility requests or interface schemes for corporate security and privacy of user information. Likewise calls for compatibility upgrades to Capital’s many adapter integrations or bridges – like to Mechanical Computer Aided Design (MCAD) and Product Lifecycle Management (PLM) and even system & workflow based change requirements collation and tacking systems notably IBM Team Concert using the IBM Jazz user interface. Modified new versions of these systems of data target or source produce enhancement requests to increment Capital functionality.

You will be best placed for success by early discussion with your Mentor team representatives and the product development staff at Mentor Graphics IESD division.

2.      Requests which are asking for improvement and modification of something already in Capital.

In this category – pertaining to the user interface, processing steps and the underlying data model and storage of information there some quick tests you should subject your proposal to assess if a realistic chance of success exists.

Test for comprehensiveness. Let’s say you see an opportunity in the part selection dialog (PSD) of Capital to do something in a more appealing way. The PSD is in Capitals Logic, Harness XC, XC Modular and Formboard, Insight, Integrator, TVM, MPM. Change it for one, you change it for all – thus lots of coverage testing of a change. Plus all users of all those modules at a new version with a different functional outcome will need to be informed/trained as to what to expect. Imagine a thousand users sat in a huge room, used to doing things one way and then judge whether the improvement you advocate is still significant, or will be welcomed.

There’s a down-vote as well as a promote option on Mentor Ideas for IESD. It is not often used, but if you see a proposal which would disadvantage the way your company works if realized, say so. Consider when you offer your own schemes whether it may cut across the wishes of other users in other companies.

Capital is a highly configurable software system – and in many aspects of the user interface there are opportunities to modify what appears. In PSD case librarians can do a lot to prepare data or pre-filter user choices. Assigning properties, domains and even scoping attributes to components for example may give the flexibility you seek. It may not get you exactly where you would like to be in the best of all imaginable solutions. Check there is no viable alternative configuration step which will alleviate your concerns.

3.      The type of enhancement request which relates to a newer part of the Capital Product family.

As a rule of thumb expect to have more chance of success with a newer part of Capital. Once into “maintenance” mode – development organizations are more likely to be shy of introducing improvements. The thinking is the market has accepted and got used to the software the way it is, and so many ideas’ merits will be somewhat suppressed in priority by this. To developers – stable code inclines them to think “it ain’t broke”. So make your argument forcefully if you think it is.

Capital modules of in the first 3 – 4 years from their initial commercial release tend to attract more requests for enhancements. Capital TVM and Capital MPM and Capital Modular XC are therefore good targets right now if you have some improvements you want to suggest.

4.      The type of request which is popular and benefits numerous users.

Mentor Graphics is in the business of making customers happy. More users at more customers, happy piled up on happy.

I remarked earlier that there is a disproportionate representation of sysadmin and librarian functional enhancement requests. Exactly how does one count users? Remembering that not all enhancement requests are equal and will not be treated as equal, you should wherever possible quantify the number of users who will benefit. Prioritization by Mentor of the requests which express the greatest good for the greatest number is what you should expect.

A modifier to this utilitarian principle is “the more users whose purchasing power is extraordinarily potent the better.” VeSys customers are numerically more plentiful than Capital customers, but Capital Users are very numerous, clustered into bigger companies, represented by more expert users and outspend VeSys so Capital is more bountiful in Mentor’s view. Investigative journalists follow the money trail in their work, software product managers in for-profit companies do something similar. They pay attention to the revenue stream, just like you, the commercial users of their commercial product do.

Prod the product managers by indicating the clear refreshing value stream of happy on happy and repeat business flowing like revenue down a prosperity mountain.

So let’s all be happy. Happy New Year for 2015, and happy new release for Capital Users for the 2014.1 version.

The previous blog described why software vendors build out their off-the-shelf products with arrangements for functional extensibility. Also I reviewed what motivates companies designing and manufacturing transportation electrical interconnect to expect, ask for and then subsequently use an Application Programming Interface (API). Now, drawn from my experience of Capital’s deployment at customer sites around the world, you can read about some reasons why taking advantage of Capital’s extensibility is a constant and how that worth is appreciated by users. It is worth reading because the benefits can be substantial to your company.

Essential for joined-up processes

Software applications which accomplish tasks as if they were independent of a need to interact across environments or domains do a disservice to the companies which in a true enterprise environment require interoperability. Enterprise applications have to interface with one another in order to be successful within a modern business. Data needs to be shared between multiple applications so that it can be tracked and traced throughout a product’s development lifecycle. These applications also need to be extended to ensure they meet the particular customer requirements. Flexibility includes the capability to model and store the business rules and what is referred to as the Intellectual Property (or IP for short) use in the design methodologies. Here is often some of the core private foundations of the competitive edge you have over rivals.

Applications talk to each other through data transfers in and out. Processes for import and export are handled in a part of the system called Capital Bridges. Services for data take-on for designs, services for library import, merging and blending are presented in user interfaces based on the extensibility technologies of Capital. When you expose the data model so it becomes interdependent for information to what is happening in other systems you get in return plenty of benefits.

Enabling transfer in and out of data without the formalized arrangements and structural support of Capital Bridges’ licensed products like those to Catia and Creo and NX Mechanical Cad systems are based on extensibility principles. Sharing of data is one set of benefits – using events and data conditions to trigger actions back and forth between systems is another advance which users are increasingly coming to expect. In Capital this is achieved with the Web Services links. Furthermore, special data conditions – based for instance on the way you have chosen to customize your mechanical CAD models with property tags – can be the subject of specially written bridge processor extensions done in-house or by bought-in talent like that provided by Mentor Graphics Consulting division.

Mentor Graphics Consulting experts do not get any more access through the API or extensibility provisions than your in-house staff do, it just so happens that they are likely to be more experienced, having worked on several similar projects before yours. Your own people will perhaps be partnering with consultants to learn from their experience to make the best time to productivity.

Why do you choose to use the API?

Every organization has special requirements, and I am sure yours is no different. One maxim I use with customers who are adopting Capital is: “it is not a matter of whether you want to extend Capital or not to meet your specific needs, the question is, how far do you want to go and how often?”

Typically, adapting the extensibility features to their individual needs is one of the more innovative experiences of deploying Capital for customers. Plans for extensibility and making plugins stay fluid as customers get into new ways to deliver innovation, in the same way the business of design and progression to manufacturing is done. It is also normal for this innovating phase of picking up use of the API functionality to take place after the first wave of deployment projects’ data populates the databases. One of the exciting yields for stakeholders at this time of using plugin reporting and validation is to explore new ways to understand your business, as you explore new analyses of your data, which arise, from your business activity.

Customization vs. Extensibility

For some companies the word ‘customization’ is taboo. The combination of enterprise software and a history of customizations entail past experiences they do not wish to repeat. Production deployed software may be perhaps 10 years old or more and has not been kept up to date because of the level of customization. Defunct hardware and unsupported operating environments represent a business risk. Capital does not carry these risks with it.

The notion of extensibility is different. The Capital API is designed detached from the core software. Extensions can be created freely without fear of interfering with any of the core tool functionality. This means that future upgrades to the software can occur independently of any plug-in development. Upgrades do not carry a threat of service interruption or denial.

Application Programming Interfaces are a way of producing functional additions run inside the larger commercial off-the-shelf application. The best examples of API’s therefore retain all the validation and control (like security layers etc.), whilst still allowing customer innovation. Don’t be fooled into thinking this is an abstruse subject. It is intensely practical. Real problems are solved and there is a happy situation of multiplication of benefits when this becomes a mechanism for innovation. If your API sidesteps, circumvents, ignores, or sneaks around your quality and security processes for example – that can force on you tough lessons learned about allowing access to sensitive data. Capital will not do that.

Two examples of how the API is useful.

Here is an example. A manufacturing plant will only accept the harness BOM when it matches a certain format and includes some additional attributes. Off the shelf Capital provides ways to modify, or alter, a table or report. More often than not there is not enough flexibility to provide you with the exact format required. However let’s speculate that there is a special set of conditons for the BOM format which cannot be met. With very little effort, a Java programmer could create a custom version of the BOM that can either be printed on the diagram, or created as a static report. That plugin can be added to the set already provided in Capital HarnessXC. Not only is a difficult case quickly closed, the table can be automatically added to the face of every harness that goes to that factory thanks to Capital’s styling technology.

Here is another example. You have a requirements that no multiple terminations can be present on a sealed connector, or disallow placement of connectors of a certain sub-type in hazardous or harsh environment areas of the vehicle. Let’s assume too it is unlikely that any commercial tool has a validation “out of the box” to detect these situations – Capital Logic has around 70 out of the box but let’s go with the assumption. It will be the work of just perhaps an hour or so, for a java programmer to author and apply this check as a custom Design Rule Check in addition to the set already provided in Capital Logic. A tricky localized use case is swiftly deal with – and you can also determine that a design cannot be saved or released if there are cases of wiring that breaks these rules.

The above picture is from my Capital system, and I’m at the moment using just over 50 API utility extensions.

What do you invest in to use the API?

I have asserted – a programmer familiar with java (not an expert programmer) will take “perhaps an hour or so” – and if this person is hired on as a staffer in your company, or hired from outside as a consultant or contractor that attracts an hourly rate. My observation is that usually a good slab of API programming time will be spent on creating new DRC’s. Checking experience with other colleagues, their observations are that making special reports is often the priority that customers work to. And of course the user time specifying and refining the requirements, acceptance testing the code is time you may account for in your tracking system as not actually interacting with customers. These investments in future productivity are well worth it. The value in removing errors and thus eliminating quality problems, automate reviews, supplement documentation

Usually it is a good idea also to have someone write up the usage methods for the plug-in code, which is used in your system. This investment in process definition with your software tool also ensures you minimize training overhead.

In-house or external resources can create and re-purpose code quickly for you

Time is money. Talk is cheap. Talk takes time. So either talk is not cheap or time is not money.

Also reducing the time to productivity is the copious reference documentation resources which are installed with Capital. Other API’s can sometimes provide a toolkit without anything other than the barest of instruction. Capital is different.

You have a plethora of printable, readable material on all aspects of the subject. Supplemental resources on the IESD community site come from Mentor Programming and Product management people, to which any customer with a current maintenance contract may contribute. If you are the person actually doing the programming, as a “last last” resort after looking at the manuals and perusing the examples and advice from the practitioner friends out there in the community, phew …. well there might be your worst programmer fears coming true and you actually have to speak to someone on the phone or have a web meeting and talk. Hear some nice polite and generous guidance from a fellow human being.

Your people using the Capital API are valuable to you, so Mentor equips them with the best.

Your own IT experts historically have been solving practical business problems with IT tools and solutions. Perhaps as they have crafted integrations, extensions they have been used to languages and environments which are more suited to Microsoft Office documentation solutions perhaps rather than enterprise data-store-scalable professional tools. The Capital API being tightly coupled into the corporate design environment and locked in to IT governance policies which minimize your exposure to business risk is also an aspect of the unexpected benefits you get for choosing this way of working.

It is a safer, faster, cheaper method of extending and personalizing your Capital repertoire. Professional services costs are under control – the know-how of your business is kept firmly in-house. Empowering your talent pool with enterprise class tools and allowing them to trade up from the basic scripting/macro building technologies of brute data manipulation in office automation products is good. Very good for career development and for giving your valuable IT employees who you want to retain an interesting job to do now – and learning platform-agnostic Java if they do not already know it – which will usually have an impact for other domains than Capital too.

Activation by license.

The operation of the API is governed by a licensed product called Capital Integration Server (CIS).  All additional coded plugins depend on the presence of this license for a user to have the chance to load and run them.

Design Rule Checks, Design Inspectors, custom actions, custom-designed tables which appear styled into the diagrams etc. have a running CIS process as a prerequisite. Likewise any pluggable authentication programs or web-service based sub-processes consumed or hosted, like those involved in event publication and subscription triggering. Thus does this purchased CIS license underpin integrations between Capital and other systems – enabling for many customers a tremendous amount of automation and validation, yielding a continuous return in efficiencies and elevated product quality, decreased engineering time.

These are the things you can write in the API which will help Capital users every day they work in the software.

 Used by people with time pressures.

Extended functionality achieved by using the Capital API is, well, not just an extension but an addition to the value you get from Capital as a user. If someone has given you a custom DRC it means that you are confirming, without manually checking through a data source, quicker and more accurately the state of your data, and therefore building quality in to your product. Data can also be augmented using the API – again a faster and less error prone process than using manual means. Data can be transferred or pulled automatically – for example to a Product Lifecycle Management system (PLM) – saving staff time and effort and ensuring compliance with corporate governance directives. Less time doing things which don’t directly contribute to the electrical system design, less time “minding and ministering to the machine”

If you are a Capital user this means you get more time to do the job you are paid to do and are good at and enjoy doing. More of what you like to do. Fewer things you have to do which aren’t what you like to do. The more time you spend creating data, and the less time you spend validating it, the more productive you will be and the business as a whole will see the benefit.