|
|
|
|
|
|
|
|
The Java Community Process (JCP) program applauds the community's Star Spec Leads.
These leaders earned this honor through their efficient, prompt, and transparent
communication with their Expert Group, the Program Management Office (PMO), and the
Executive Committee (EC). They used community web pages, observer aliases, and other
tools to communicate with their expert group, the JCP program community, and the public.
They kept their Java Specification Requests (JSRs) on schedule by making sure their team
stayed focused and felt appreciated. The JCP program congratulates and honors these Star
Spec Leads. |
|
As Java ME Technology Development Manager for Motorola Mobile Devices, Mike Milikich is focused on Java Micro Edition (ME) standards, implementations, tools, and Technology Compatibility Kits (TCKs). He leads and manages teams in Chicago, Illinois; Austin, Texas; and Sunnyvale, California. For the last 15 years, he has designed software architectures for mobile and wireless devices, including pagers, Personal Digital Assistants (PDAs), cell phones, and even some devices that defy categorization. Before that, he worked on software development and architecture for the industrial controls industry, items such as programmable and numerical logic controllers.
Mike received both a master's in Computing and Information Sciences (1991) and a bachelor's in Computer Engineering (1983) from Case Western Reserve University. His master's thesis focused on the use of associative neural networks as a method of industrial control, replacing components such as proportional-integral-derivative (PID) closed-loop controllers.
In 1995, Mike first began working with Java technology. At that time, Motorola was developing its first Java technology-based device, whose forerunner was a string of wireless PDA-type devices, including the Motorola Envoy. Most recently, Mike has been helping the Motorola Mobile Devices group develop Java ME strategy, standards, and open source solutions, as well as more specific Application Program Interface (API) reference implementations and conformance testing. In these projects, he has acted as an end user, developer, technical lead, and development manager.
In collaborating with Jim Van Peursem as a development manager for Motorola's MIDP2 device implementations, Mike began participating in 2001 in the JCP program. Since that time, he has served in various ways, including representing Motorola on the Java ME Executive Committee (EC) and contributing to the following JSRs:
- JSR 37, Mobile Information Device Profile for the J2ME Platform (MIDP1) - Maintenance Lead
- JSR 118, MIDP2 - Maintenance Lead
- JSR 180, SIP API for J2ME - Expert
- JSR 248, Mobile Service Architecture (MSA) - Expert
- JSR 249, MSA Advanced - Expert
- JSR 253, Mobile Telephony API (MTA) - Expert
- JSR 271, MIDP3 - Spec Lead
- JSR 307, Network Mobility and Mobile Data API - co-Spec Lead
Like many Spec Leads, Mike learned from his predecessor, Jim Van Peursem, who structured and ran the MIDP2 Expert Group. He says, "The previous successes of MIDP2 in terms of device implementations meant that, when MIDP3 was started, there was tremendous interest in not just maintaining, but enhancing the technology to meet the growing needs of the mobile devices community. As was done in MIDP2, the MIDP3 Expert Group took a very inclusive approach to ensure broad representation from device manufacturers, operators and carriers, and content developers." As a result, the Expert Group encompasses over 120 participants, which makes the Expert Group much larger than normal and tremendously rich in technical background, covering every aspect important to mobile devices.
With such a large and diverse Expert Group, specialized processes and tools were needed to organize and communicate effectively, with an eye toward reaching consensus and maintaining transparency. Methods that had worked for MIDP2, such as using mailing lists for each major functional area of the spec, didn't work as well for MIDP3. "We needed a more structured collaboration home for the Expert Group, one that could be used to sort out the myriad new requirements and proposed changes," says Mike.
He created a project at http://opensource.motorola.com/sf/projects/jsr271 to get the group organized. Online discussion forums for each functional area replaced the old mailing lists, and issues trackers and document repositories were incorporated. All of the JSR 271, MIDP3 spec sources in javadoc and html were made available online for any Expert Group member to edit and commit changes based on group consensus. These tools helped distribute the immense workload and get many more individuals involved in directly editing the spec.
"My basic approach has been to be completely open and work to make sure that there are no surprises in the Expert Group," says Mike. The MIDP3 Expert Group holds a teleconference nearly every week. All discussions, documents, issues, Wiki pages, and so forth are available to any Expert Group member. About every ten weeks, the Expert Group meets face to face.
The in-person meetings are the only area in the MIDP3 Expert Group where access is restricted, and then only adequately handle such a huge group. Larger meetings take on the dynamic of a lecture rather than of collaboration, most meeting rooms can't accommodate more than 30 seats, anyway. To prevent the size of the group from impeding progress, Expert Group member companies are divided into two groups. "Participants" have direct influence in the space, and they are given first shot at a seat in the meeting. "Reviewers," those without direct influence, sign up for the remaining open seats. This arrangement makes sure the topic at hand gets attention from the industry segments it is intended to serve.
The task of leading the MIDP3 team to consensus required laying out a roadmap that all could agree on, and then following up to meet commitments and goals of the roadmap. "Most of those in the EG have other work besides MIDP3 or standards, so it's important to get people to be honest about what they can realistically take on," says Mike. Then progress is made by moving forward, week by week, always driving toward the next milestone. "We started with a very aggressive schedule and had to modify it several times based on how large the MIDP3 scope turned out to be. While this has resulted in more than two years of work already, the process we're following outlines a clear path, so there's no confusion in the Expert Group about what remains to be done and when we expect to be done."
It took a while to figure out what exactly needed to be produced. First, the team decided who the spec was for. Then they developed and refined use cases from the perspective of each of those domains, and they condensed those use cases into a list of requirements, eliminating redundancy and conflicts. Next, they developed a template for design proposals that could be used to cover a stated set of requirements. Finally, the Expert Group "iterated over" the designs until they were incorporated into the spec. In this way, they made it more likely that the MIDP3 spec would include only what was necessary to meet specific use cases, not extras or unjustified features.
When content issues come up that require Expert Group collaboration or additional work, Mike tries to respond immediately, even if that answer is simply "I don't know; I'll look into it." Ultimately, he makes sure the question is directed toward a discussion forum so everyone can see the question and response. If a "domain expert" is better equipped to comment, he confirms they are monitoring the discussion forum, and if an answer or acknowledgement isn't posted within a couple of days, he contacts them directly to make sure they've seen the question. If the question is outside of the scope of JSR 271, Mike refers the question to a more relevant entity, such as another Expert Group, or he'll point to his group's earlier decisions to explain why something wasn't included.
Mike asks group representatives from each company to gather and organize comments originating outside the Expert Group into the appropriate issues tracker. Issues are "triaged" before each teleconference to determine which are simple fixes, and which require deliberation within the Expert Group. "For face-to-face meetings, we've developed a pattern of reviewing very large portions of the spec against the open issues that relate to it," says Mike. He communicates beforehand with the domain expert or designer of the spec segment under review to ensure they are available to discuss their contributions and answer questions. Some issues remain open for quite a while, but the goal is to recognize where very large efforts exist and plan for the communication, time, and resources needed to resolve them.
Mike pays attention to the PMO's cutoff dates for submission. He has found that getting in touch with the PMO early is helpful, especially for a spec that has as many components as MIDP3 and that does not have a collaboration site on jcp.org or java.net. He proactively sends snapshots or "checkups" to let the PMO know the group's scheduled milestone status. "From past experience we've learned to communicate clearly and early when preparing a stage submittal," says Mike.
Mike is now a Star Spec Lead. "To be recognized in this way, given the knowledge and expertise of those in the JCP community, is to me the highest compliment. And as any Spec Lead will tell you, nothing in any Expert Group happens without the input, collaboration, and very hard work of a lot of individuals," says Mike. "Any success that I have had or will have in the JCP program is in no small part due to the incredibly smart people I've had the privilege to collaborate with."
Looking ahead to the future of Java ME, Mike speaks with intensity about major changes that he feels need to be made. "I'm convinced that to continue to be successful, a business friendly, open-source solution for Java ME is critical. Application developers need to be able to rely on more consistent Java ME API implementations, handset manufacturers need to be able to share API implementations across device platforms, and operators and carriers need to be able to deploy single versions of proprietary applications on any device on their network," Mike says. "Much of the promise of Java ME has yet to be realized because there are so many varied implementations of standard APIs. A single open source code base will allow the Java ME ecosystem to benefit from the economies of scale seen elsewhere in the open source world. A lot of effort is repeatedly expended to implement standard APIs that are expected to behave identically on many platforms; the proven absolute best way to do this is to actually share as much of the code as possible."
Mike has lived in several US cities, including Cleveland, Chicago, and Atlanta. He now makes his home in Round Rock, Texas, near Motorola's Austin Innovation Center. Most of his free time is spent with his wife Ginny and their two kids, ages 9 and 7. A big baseball fan, Mike volunteers as a baseball coach and tries to squeeze in as many Round Rock Express games as possible (AAA affiliate of the Houston Astros). He also enjoys cycling, running, and homebrewing, not necessarily in that order.
Go to the Star Spec Lead Program page for more information.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
|
 |
|
Mike Milikich