Much of the world's great art was produced by a process of "previsualization" – envisioning the artwork on the wall and working backwards from that point. Engineering design, no less an art form, benefits tremendously from visualizing the end product, considering its utility, and repeatedly asking the question, "How do we get from where we are now to that destination?" True, it's a recursive process, and you shouldn't be afraid to move forward simply because you've never been on this trajectory before. You'll have to make some mid-course corrections, but if you want to chart a course, you have to determine where you want to go. And sometimes a few small experiments and some difficult but critical mathematical analysis at the beginning of a project can make all the difference.

This is what system architecture is all about.

Our customers include both large firms and small startup companies. And we'll be honest: We don't always sell the biggest of them our architectural design services, per se. Often they've already been through the previsualization process and arrived at a viable architecture themselves. In that case the value of our being able to do good system architecture ourselves lies in how quickly we can grasp theirs, since that translates directly into a corresponding ability to hit the ground running as we implement a solution.

With smaller companies, and particularly with venture capital or angel funded startups, we frequently find that the electronics package is an "enabling" technology. Perhaps our client has a new medical process that requires an instrument to measure a chemical reaction, and the patentable material is all in the chemistry (and not the electronics). Or he needs the control system for a complex mechanical device; and again, the mechanical chassis lies at the heart of the intellectual property. But without a good electronic architecture that dovetails well with the customer's patentable technology, the "secret sauce" in some other discipline can't be bottled and sold.

When the exit strategy for an investor in such a company is via merger or acquisition, money spent internally building the infrastructure for an "enabling" technology (such as the electronics required to read the results of the new biochemical process) rather than a patentable one (the organic chemical reaction itself, perhaps) can have such a comparatively low rate of return that a promising startup simply can't tolerate having its limited assets tied up in the investment to develop it in house. Companies like these therefore depend on us to make their product offering the best it can be. Even though we may not be in the spotlight, we recognize our serious responsibility to them.

Let us take a look at your opportunity to create the architecture for the next great product. Our broad base of skills gives us the ability to see many possible solutions to a problem – including yours.

Skills Focus Embedded brings to bear on architectural design include:

• An understanding that Pareto distributions are everywhere and that 20% of the features of a product will often get you 80% of the market.  We’re experienced at helping our customers (and their investors) find the sweet spot that is the “minimum viable product.”
• An understanding of the market. We want actual development times and costs to align with your business model, and we'll do the homework to make sure that we're all operating from the same set of expectations before we begin the project. Good engineering is, after all, technology applied to solve a problem in response to the demands of the marketplace.
• An understanding of Laplace, Fourier, and discrete transforms. We do the math that tells whether a solution is even physically possible, and, if so, what its limitations will be before anyone arrives at an implementation that "almost works."
• An understanding of analog electronics and SPICE that enables us to predict circuit behavior in the real world of component tolerances, manufacturing variations, and environmental conditions.
• Knowledge of the digital vs. analog tradeoff. The real world is an analog place, and some things are better done with simple analog solutions. But digital solutions inherently provide timing and noise margins so long as you're willing to pay the price of quantization errors. Further, mathematical models simply exist – without component tolerance or drift – so there can be compelling reasons to use digital systems and embedded firmware.
• Knowledge of the hardware versus software tradeoff. Some things just have to be done in hardware, but to the degree to which you can make a hardware problem a software problem, you can dramatically reduce cost of goods sold. Software is also impervious to component tolerances, aging, and manufacturing variations.