CHICAGO- January 2012- After 5 years of being stationed just outside of Chicago in Park Ridge, IL, Delivered Innovation, Inc. is excited to announce that they have moved their Headquarters to Chicago as of January 1, 2012.

Delivered Innovation needed a larger office space to accommodate business expansions and quick growth. The new office is located at the corner of Chicago Ave. and Milwaukee Ave., in the River West neighborhood of Chicago.

“Finding a new office location had been on our radar for nearly a year now,” says Michael Topalovich, CTO and founder of Delivered Innovation; “It is crucial for the growth of the business to be in a space that is easily accessible to employees and clients.”

Delivered Innovation has experienced significant growth in the past year, doubling their staff and gaining larger clients that entail complex CRM projects built on the Force.com and salesforce platforms.

Delivered Innovation’s new address is 688 N. Milwaukee #202, Chicago, Illinois 60042. Phone and fax numbers remain the same.

More about Delivered Innovation
Founded in 2006, Delivered Innovation (DI) designs and develops on-demand SaaS business applications. Utilizing leading cloud computing technologies and leveraging strategic partnerships, DI helps clients address complex business challenges and create revenue opportunities by automating business processes, extending the functionality of existing CRM enterprise systems, and introducing new business capabilities within Salesforce.

DI understands the critical nature of getting services to market quickly in order to capture first-mover advantages. Additionally, DI understands that it is just as important for services to be well-designed, highly functional, and high performing in order to drive rapid adoption and growth. With DI’s innovative approach to SaaS application and design, they have completed over 125 successful projects, ranging from innovative startups to global 500 companies.

Links
www | Force Architects Blog | LinkedIn | Twitter | Facebook | Tumblr | Google+

Media Contact
Jessica Buhrman | Social Marketing Manager | jbuhrman/deliveredinnovation.com

As I was cleaning up some documentation for an onboarding session that I will be conducting for new Force.com developers that have recently joined the Delivered Innovation team, I realized that the Force.com architecture design principles that form the foundation of everything we design and build might be of value to the community, so I am posting them here on the Force Architects blog. These principles have been gathered from lessons learned on customer projects, from other developers and architects that we have had the privilege to work with, and from books and documentation that we have read and learned from. Let us know what you think, or if there are other principles that you follow that we should consider adding to the list.

—

When working with cloud computing platforms such as Force.com, our architecture must assume that design will evolve over time and that we cannot know everything that we need to know up front in order to fully architect the solution. Our design will generally need to evolve during the implementation stages of the application as we learn more and the design is tested against requirements and feedback from both business owners and customers.

We have to create our architecture with this evolution in mind so that it will be able to adapt to requirements that are not fully known at the start of the design process (what we refer to as either “known unknowns” or “unknown unknowns”). As we design for Force.com, we must consider the following questions:

• What are the foundational parts of the architecture that represent the greatest risk if we get them wrong?
• What are the parts of the architecture that are most likely to change, and which parts of the design can we delay until later with little impact?
• What are our key assumptions, and how will we test these assumptions?
• What conditions will require us to refactor the design?

When getting started with our design, there are a number of key principles that we need to keep in mind to help create an architecture that leverages best practices, improves speed to market, minimizes costs and operational requirements, and promotes reusability and extendability. The key principles are:

• Abstraction. Split up the design into granular features with as little functional overlap as possible. The primary challenge is to segment functionality at the appropriate layer of the architecture to cut down on coupling and complexity.
• Distinct Areas of Responsibility. Each component needs to be responsible only for distinct features or functions, or the aggregation of similar functionality.
• Principle of Least Knowledge. Components should not know about internal details of other components or objects.
• Limit Repetition. Specific functionality should be implemented in only one component; the functionality should not be duplicated in any other component.
• Only Design What is Necessary. The amount of upfront design should correlate to the risk of getting it wrong. In our agile methodology, if requirements are not clear, or if the design will evolve over time, spending too much time on design upfront may not make sense as the design will be fleshed out throughout subsequent iterations. It is important, though, to make sure that this iterative design is managed within the scope of our overarching architecture principles and that the final design is tightly integrated with the overall solution.

When designing a Force.com solution, the overriding architectural goal is to minimize the complexity by separating the design into different patterns and components. For example, the user interface (UI), business and validation rules, and data model all represent different patterns with various components. Within each area, the components we design should focus on that specific area and should not mix code from other areas.

• Keep design patterns consistent.  Wherever possible, components should be designed to be consistent for the function that they perform within the given architecture layer. For example, if ExtJS navigation patterns are used to create a wizard function, you should not include another pattern such as a Flex container, which uses a different method for accessing data and initializing business logic, and creates an inconsistent look and feel. However, you may need to use different patterns for tasks in an architecture layer that have a large variation in requirements, such as a requirement that is highly transactional or requires robust reporting functionality.
• Avoid duplicating application functionality. If you have a component that provides specific functionality, it should be the only one providing that functionality; it should not be duplicated elsewhere. This allows components to be usable by other components and makes it easier to update components if a specific requirement changes. Duplicating functionality within an application makes it difficult to implement changes, creates inconsistencies over time, and eventually creates operations overhead.
• Establish a coding style and naming convention for development. A best practice is to use common standards for coding style – things such as indentation, line spacing, capitalization, inline documentation, etc. enable consistency and makes it easier when we have multiple team members on a project reviewing code that they did not write.
• Maintain system quality using test classes for QA automation. Leverage Apex test methods for unit and integration testing and other automated QA techniques during development. Define clear performance and behavior objectives for components, and build test classes and methods concurrently with core Apex code to ensure that design or coding decisions do not impact the overall quality of the application.
• Take operations into consideration. Determine what metrics and operational data are required to ensure the efficient packaging, deployment, and operations of the solution. Designing components with a clear understanding of their individual operational requirements will significantly ease overall deployment and operation.

—

Acknowledgements

1. Frederick P. Brooks: The Design of Design: Essays from a Computer Scientist
2. Microsoft Patterns and Practices Team: Microsoft Application Architecture Guide (there was a time when Redmond knew what it was talking about)
3. Force.com Development Lifecycle Guide

Delivered Innovation’s “Cloud Architecture Weekly Roundup” series needs a better name. The weekly post includes links to interesting cloud and Force.com related stories along with a brief summary for each (check out last week’s Roundup here), and we are turning to our readers to help us pick a more interesting name. Brainstorm some new names for the weekly post, and the winning entry will score a $100 Amazon gift card.

To participate, tweet your suggestion along with a @forcearchitects mention and the hashtag #DIContest before noon CST on Friday, February 25th. Winner will be announced later that afternoon.

There is no limit on creativity or the number of submissions.  Have fun, and drop us a DM if you have any questions.  Happy tweeting!

You do not have to be a member of the ITA to attend but you do have to register here for the event.  Everyone is invited and all are welcome.

http://www.illinoistech.org/event.aspx/2926

Glenn Gruber: The Fallacy of Software Factories and the Importance of Talent

Mr. Gruber makes a number of good points in this post regarding the general tendency in IT to try to commoditize talent within the software development space. While we at Delivered Innovation employ a “factory approach” to development, our philosophy regards the standardization of the delivery process itself, and not the application of tacit knowledge to the process of creating value, as the ultimate candidate for standardization. Glenn is spot on in his assessment that many firms within the outsourcing world try and apply a factory model for the purpose of reducing development expertise to the least common denominator, and this comes at the expense of quality design…and ultimately of quality output.  DI has been brought on to a number of large “cleanup” projects in the Force.com space this year to untangle messes created by these so-called software factories where developers are routinely referred to as “bodies” (as in, “We’re behind schedule, so let’s throw a few more bodies at this”), and in every case the customer ended up spending significantly more on the project using resources that may have cost less on a per-hour basis, but ended up costing more in the long run due to the watered-down skill levels and lack of insight into the big picture design and architecture.

Three key points:

…under the traditional outsourcing model success (i.e. margins) is achieved by trying to break any task down into its most basic components so that those activities can be completed by the most junior and cheapest resources.

Tools and methodologies are more like guiderails to reduce mistakes and help less-seasoned developers accomplish more advanced tasks, but don’t necessarily guarantee well written, high-performance software.

Architecting, designing, building and testing products that are tied to revenue, that require high levels of performance, scalability and resiliency is not a task to be done by lowest-common-denominator individuals.