This is a joint presentation made at Localization World 2013 in Singapore. It developed out of a client engagement seeking an optimal solution to taking a large complex service across language borders.
2. Introduction to EnerNOC
Founded in 2001; NASDAQ (ENOC); 700+ employees
Cloud based energy management services for commercial,
institutional and industrial customers
Two main offerings:
o Demand Response software & services – real-time balancing of
electricity demand and supply
o Energy Efficiency software & services – reduce/monitor energy usage.
Over $600 million in customer payments/savings to date
4,900 customers across 11,400 sites with 7,100 MW’s of
demand response capacity in North America, Europe,
Australia, and New Zealand
3. Balancing Supply & Demand
Every second of every day, the Utility must
ensure that there is enough electricity supply to
Grid
Disruption
meet electricity demand.
Available
Electricity
Supply
EnerNOC’s Demand
EnerNOC’s Demand
Response Network
Response Network
Dispatched at RecordDispatched at RecordBreaking Levels at Utility
Breaking Levels at Utility
Electricity
Demand
Time of Day
4. How Demand Response Works
When the grid needs resources, NYISO “dispatches” EnerNOC’s resources and
thousands of enrolled facilities reduce electricity consumption, avoiding disruption
7. How Hard Can it Be?
Initial impression underestimated task
o Good intentions
• Prior international experience in UK, Australia, Canada
• Strategic business direction
o Unexpected acceleration of plans
• Urgent opportunistic need in non-English, non-alphabetic
language
• Other promising non-English opportunities
On closer inspection …
o Tasks larger & more complex
• Lead time is also an issue!
o Need for education
• More than just translation & some code changes!
8. Plan of Action
*
We are here …
… but we need to mature
* Source of Localization Maturity Model:
Common Sense Advisory
9. Plan of Action
Education
o G11N, I18N, L10N
Urgency
o Brute force option?
o Minimum Viable Product?
o What about Technical Debt?
Expertise
o I18N Readiness Assessment
o G11N Program Management
10. Definitional Interlude
Whether B2C or B2B …
All of these are designed for
individual (single-language) use …
What about B2B collaboration and
multiple-language environments?
11. Cost Drivers
Localization (L10N)
Visible
Effects
(Locale Costs)
Enabling
Capabilities
(Cost Control Mechanisms)
o Interface
o Documentation
o Content
Internationalization (I18N)
o Software
o Data Storage
o Processes
Globalization (G11N)
Strategic
Decisions
(Primary Cost Drivers)
o Business/Operations
o Customers/Partners/Staff
o Language Support Requirements
12. Plan of Action
Education
o G11N, I18N, L10N
Urgency
o Brute force option?
o Minimum Viable Product?
o What about Technical Debt?
Expertise
o I18N Readiness Assessment
o G11N Program Management
13. Urgent Call to Action
Brute force option? Considered & Rejected
o Incomplete “solution”
o Multiple code bases
o Delays the inevitable
Minimum Viable Product? Preferred Option
o Depends on G11N Strategy
o May change over time
What about Technical Debt? Manage It
o Minimize whenever timeline allows
14. Plan of Action
Education
o G11N, I18N, L10N
Urgency
o Brute force option?
o Minimum Viable Product?
o What about Technical Debt?
Expertise
o I18N Readiness Assessment
o G11N Program Management
15. Adding Expertise
I18N Readiness Assessment
o
o
o
o
Focused activity on core platform
Addressed Minimum Viable Product challenge
Identified risks to be considered
Identified links to G11N strategy decisions
G11N Program Management
o Brings together business and technical ‘tracks’
o Sets stage for future expansion
I18N Outsourcing Partner
o Part of managing Technical Debt
16. Business Challenges
Is “English-only” viable for the Network Operations
Center (NOC)?
Does “English + Local” work for external
communications?
How can US-based program set-up processes best be
internationalized?
How can US-based event notification strategies best
be adapted to local custom & technology?
How can Demand Smart I18N investments be
leveraged for other products?
17. Technical Challenges
Complex Architecture
o Multiple platforms
o Multiple points of integration
o Multiple user groups
Ongoing Development
o Backlog of prior commitments
Multiple Coordinated Deployments
o Single NOC Multiple Coordinated NOCs
Performance & Latency Issues
o Real-time event management/monitoring
18. Minimum Viable Product
Depends on G11N strategy decisions
o Scope of Joint Venture responsibility
o Scope of Demand Response programs supported
o Internal NOC staffing (bilingual?)
Depends on locale
o Tolerance for English
o Support for various automated notifications
Depends on time
o Initial “MVP” may not be viable in future
19. Results to Date
Funded MVP I18N effort
o Hired I18N outsourcing partner
o Included rearchitecture of main platform
Initiated G11N program
o Raising internal awareness through training
o Identifying areas of I18N risk
• Uncertainty & Variability
o Informing business decisions
Ongoing I18N activity
o I18N as a process, not a one-time effort
o I18N incorporated into “business as usual”
20. Evolution of Maturity
Cultural change G11N maturity
o Not just a translation of text
o Not just one application/system
• Processes span applications and language barriers
• People (and their attitudes/awareness) are key
o
o
o
o
Not just an engineering problem
Teach technology and business about I18N, L10N, G11N
Business operations – establish a G11N Program
Business strategy – incorporate G11N into decisions
Lessons Learned
o Education necessary but not sufficient
o Learn by doing – The world does not stand still and wait!
When EnerNOC saw an opportunity to expand its energy management business beyond the US market, they were faced with the challenge of localizing an application hosted on multiple interdependent platforms and intended for use by a wide range of internal and external user groups, each with potentially different language requirements. This presentation covers EnerNOC's approach to re-engineering and re-architecting to create a solid platform for international expansion, all while continuing to provide new functionality in accordance with the previously committed roadmap.
Script:
“There are three phases to a demand response event.
First, notification. When an event is called, we immediately give the facility notice that this is taking place via phone, pager and email. We maintain a list of three contacts per facility to ensure that we get word to you. If our automatic notifications are not confirmed, we will escalate to personal calls to other contacts.
Second, response. The facility responds to an event by curtailing load or shifting load to a generator. As we just discussed, you participation can be manual or fully automatic.
Third, restoration. We notify the facility that the event is over and either you restore operation or we return the operation to normal levels.”
Notes:
Depending on the program, advance notice can range from 10 minutes to the day ahead
We are constantly monitoring grid conditions and provide warnings as conditions build that an event may occur. [note to presenter: how likely we are to provide warnings depend on the program. In a weather driven summer peaking programs such as PJM, NY or New England, it is quite likely. In sync reserve programs, it is extremely unlikely. Also, warnings may not be available for tests]
We notify for fully automatic sites, too
If we know the duration of the event, we communicate this at the time of the notification
This is not intended to be an exhaustive documentation of the touch points between applications, nor is it in any sense a replacement for or competition with the more detailed architectural diagrams that Per has developed. Rather, it is intended as an abstraction of the overall process that facilitates discussion of localization vulnerabilities and I18N/L10N requirements. In particular, the blocks on the above diagram represent functional aggregations, not architectural tiers. Furthermore, there has been no attempt in this diagram to distinguish between “platform” elements (developed and supported by the product engineering team) and “unsupported” elements (developed by IT or other EnerNOC staff outside the formal “product engineering” release schedule. That said, I would still suggest that the distinction between “supported” and “unsupported” applications is significant with respect to both short- and longer-term I18N activities, and it is probably worth considering the extent to which I18N requirements constitute an opportunity to accelerate a refactoring of the entire DemandSMART ecosystem with the goal of bringing more of it under the umbrella of product engineering. This is likely to have a significant long-term financial benefit even if it entails some short-term increase in cost and/or time-to-market.
Reactive. An ad hoc response to business demands for international or domestic multicultural (also called “ethnic”) support characterizes this first phase of localization. There are few defined processes – and lots of individual heroics. Small companies, websites at any size firm, and self-contained business units of larger organizations typically find themselves at this level as they first begin responding to international market demands.
Repeatable. In this discovery phase, companies establish basic project management processes to track cost, schedule, and functionality. External translation resources and engineering resources support the effort. Firms of any size that have undertaken some international product development, marketing, and website globalization fall into this category as they begin realizing how much work is involved in localization.
Managed. Recognition of common problems drives efforts to document, standardize, integrate, and sometimes centralize localization projects across the firm. Ideally, all projects use an approved version of a corporate-standard process for localization. Larger firms – especially high-tech companies in software and hardware, consumer electronics, and automotive manufacturers – have generally reached this level.
Optimized. At this stage companies take a more scientific approach, collecting detailed process, quality, and efficiency metrics. They begin requiring localization- and language-centric tools, both by their internal development groups and by their sourcing partners. Companies with highly evolved internal processes, a modern software infrastructure, a content management architecture, and experience in distributed authoring and product development will aim for this next level of localization maturity.
Transparent. Companies in the final phase of the LMM have internalized the concept of localization so that it is a natural part of their code and content life cycles, business planning, quality management programs, and general outlook. They undertake a program of continuous process improvement in which they insert the globalization “gene” into every product, customer interaction, and employee.
Like an iceberg, the part of this “picture” that is obvious is the top portion … the localization. However, localization cost (per language) can be influenced very significantly by the degree to which effective internationalization activities have been completed. In some cases, it is impossible to deliver the desired level of L10N quality without addressing I18N concerns. In others, L10N is simply more expensive/complicated (for each locale supported) than it would be if appropriate I18N investments were made. Globalization, however, is where the most financially significant decisions are made. How do we go to market? How do the various options affect our need to internationalize our software and/or website? How do our decisions on G11N strategy affect our need to localize marketing content, website content, software user interfaces & user documentation, user-generated (or user-sourced) content, etc.? (Note that G11N “best practices” including controlled authoring for content creation, standardization on a single “official language” for internal use, full I18N/L10N cost analysis for any proposed G11N initiative, etc. can also have a significant influence on the overall financial picture.
Localization (L10N)
Interface: Ensuring that all language, date formatting, currency, and other elements appear in locale-specific forms
Documentation: Ensuring that all user documentation is presented in the local language and includes locale-specific formatting conventions
Content: Ensuring that any textual content is delivered in the appropriate language and in accordance with appropriate formatting conventions
Internationalization (I18N)
Display: Ensuring that appropriate provision is made for locale-specific variations in display characteristics (text expansion, text directionality, layout, etc.)
Procssing: Ensuring that all navigation, command, dialogue and other user interactions include logic based on a “locale” indicator
Storage: Ensuring that Unicode or other character encoding system that supports all requisite languages is utilized
Globalization (G11N)
Business: Addressing all the business ramifications of multi-national operations including taxation, logistics, legal regulatory issues, incorporation issues, staffing issues, business process issues, and many more
Linguistic: Identifying needs for support of languages other than English and promulgating appropriate policies (HR, L10N, etc.); this can affect the level of I18N & L10N that is needed.
We will display this at the end and during the early part of the break.