Introduction
The 2024 in-person Joint Command and Control (C2) Common Operational Picture (COP) Working Group (WG) meeting took place during the week of June 10, 2024, at Headquarters United States Southern Command (USSOUTHCOM), Conference Center of the Americas, in Doral, Florida. This workgroup is essential for facilitating communication and coordination among multiple Combatant Commands (CCMDs), Services, and Staff by bringing everyone together in one location. The meeting was an officially sanctioned activity led by the Joint Staff (JS) J3.
This event was invaluable, providing a platform to hear directly from each CCMD about their use of the COP, the tools they rely on, their priorities and needs, and the efforts underway to modernize systems and data to meet those needs. It also offered an excellent opportunity to network with the Joint Staff J2, our primary requirements sponsor, and the USEUCOM (EC) J2, as well as warfighters and Subject Matter Experts (SMEs).
While I can't discuss the specifics of the conversations, the conference triggered several thoughts and reflections. Over decades in the DoD Intelligence support to Command and Control (ISC2) space, certain patterns have emerged, and I plan to delve into these observations. Additionally, I will share some of our South Florida tourism adventures at the end of this post.
Remembering Mr. Craig Alford
However, this trip also brought very sad news. We learned of the unexpected passing of Mr. Craig Alford from the Joint Deployable Intelligence Support System (JDISS). Craig had been a cornerstone of the Intelligence Support to Command and Control (ISC2) community for decades, and his absence was deeply felt by all attendees. I have worked with Craig for close to two decades in the intelligence space, most recently reporting directly to him and supporting him as his technical director. The shock of this news is still settling in, and it will take time to fully process. Craig's dedication, leadership, and friendship will be sorely missed. My heartfelt condolences go out to his family and colleagues during this incredibly difficult time.
As we remember and celebrate Craig's impactful life and contributions, let us carry forward his legacy by continuing the important work he was so passionate about.
Observations
A map is not the territory it represents, but, if correct, it has a similar structure to the territory, which accounts for its usefulness.
Our discussion starts with a profound quote by Alfred Korzybski: "A map is not the territory it represents, but, if correct, it has a similar structure to the territory, which accounts for its usefulness." This quote emphasizes the distinction between a representation and the reality it aims to depict. Maps, models, and visualization tools provide us with a structured understanding of complex realities, but they are, at their core, simplifications. They serve as guides, offering a structured view of the world, yet they do not capture every nuance of the actual environment they represent.
This idea is vividly illustrated by René Magritte's iconic painting "The Treachery of Images," also known as "This Is Not a Pipe." The painting challenges viewers to distinguish between the image and the object it represents. Although the image shows a pipe, it is merely a representation, not the physical pipe itself. Similarly, in the realm of military operations and intelligence, our tools and maps are representations designed to simplify and clarify, but they are not the operational environment itself. This concept aligns with the adage, "All models are wrong, but some are useful," underscoring that while these representations are not perfect, their value lies in their ability to approximate reality effectively.
In the context of the Joint Command and Control (C2) Common Operational Picture (COP) Working Group (WG), this distinction is crucial. The COP is a tool designed to provide a unified view of the battlefield, but it is essential to remember that it is a representation, not the battlefield itself. The utility of the COP depends on the accuracy and relevance of the data it displays.
Consider the dots on a map within the COP. Each dot represents something significant — an asset, a threat, or a point of interest. But what do these dots mean in context? What are their semantic relationships? Understanding the context involves several layers of analysis:
- Confidence Level: How certain are we about the information the dot represents? Is it verified, or is there a degree of uncertainty?
- Data Type and Pedigree: Is this raw sensor data, static data, or finished intelligence? The type of data influences its reliability and how it should be interpreted.
- Correlation and Fusion: Has the data been correlated with other sources and fused into a comprehensive picture, or is it isolated information? Are there multiple dots representing the same object?
- Update Frequency: How often is the data updated? In dynamic environments, real-time or near-real-time updates are crucial for maintaining situational awareness.
- Authoritative Sources: Is the information pulled from and written back to authoritative sources, ensuring it is the "source of truth" and that everyone can see it? Reliability hinges on the integrity of the data sources.
As we delve deeper into these topics in the following subsections, we will explore the challenges and opportunities in creating a reliable and effective COP. Authoritative data sources are crucial, but they are just one piece of the holistic picture. The tools, business logic, and visualizations used to interpret this data are equally important in providing a comprehensive understanding. Regarding standardization, while it is essential, it does not fix everything. Over-reliance on standardization can be problematic in the real, messy world of distributed organizations and systems. Our goal is to ensure that the COP remains a valuable tool for decision-makers, reflecting the true complexity and dynamics of the operational environment.
Island of Misfit Toys
In our relentless pursuit of innovation and improvement, we often find ourselves on the "Island of Misfit Toys." This metaphorical place is where well-intentioned but misguided projects go to languish, resulting from waste, duplication, and small-scale innovations that reinvent the wheel instead of integrating with mature solutions. It's a phenomenon I like to call "Shiny Toy Syndrome" or "Shiny-Toy-Itis." This syndrome occurs when mature solutions are dismissed because they lack a particular feature, leading to the creation of entirely new solutions that address one issue while ignoring the bigger picture. The result? A collection of disjointed solutions that don't work well together.
Additionally, we see the rise of "hobby shops," small teams or individual developers creating quick fixes and custom solutions that may work in isolation but fail to integrate into a larger, cohesive system. These hobby shops can be useful for rapid prototyping and experimentation but often lead to fragmented systems that are difficult to manage and sustain.
Experimentation and innovation are vital, but why do we presume we need to create or replace something instead of integrating or modernizing existing, mature solutions? Too often, the mature solution is abandoned because it doesn't do one specific thing, leading to the development of a whole new solution that solves one issue but creates many others. This lack of collaboration results in disjointed capabilities across the board, much like everyone becoming their own cloud broker—a situation I have seen in the DoD. It's frustrating to see brokerages with some capabilities here and some duplicate capabilities over there, but none offering a comprehensive solution.
Specifically, solutions often lack this holistic picture:
- SW Factory and DevSecOps Tooling/Pipelines: Comprehensive development environments with standardized security scanning tools and efficient workflows.
- Paths to Production: Mature pathways to production with close parity between unclassified, IL4/5/6, JWICS, and some coalition networks.
- cATO-like Processes: Connections to Authorizing Officials (AOs) for streamlined accreditation and certification.
Instead, we see everyone trying to be a NIPR cloud broker, solving the low-hanging fruit for one environment that has been solved numerous times already, while ignoring the holistic big picture.
As a user, I want one coherent solution that addresses all these needs across the board. Currently, I need to work with multiple groups to field a product, dealing with different environments (IL4/IL5, IL6/SIPR, JWICS), various coalition partner networks, and disparate service offerings. Each group has its own certification and accreditation assessors, making the process messy and slow, which negatively impacts our warfighters. Even if these solutions are built by separate groups, it would be immensely helpful to have one portal or management spot that aggregates these into a common solution, saving time and money on integration and procurement.
Within the Joint Command and Control (JC2) space and really across the DoD, we see similar problems. Shiny new visualization tools and web-based maps frequently appear, but they often fail to address the more challenging tasks. While they might offer a single useful feature or make plotting data on a map simpler, they typically miss the user's specific workflows and context, making one thing easier but not streamlining the actual job. It's as if a data engineer wrote the frontend. These tools lack mature training and established curricula, do not incorporate the complex logic and connections developed over years, and often do not utilize authoritative data sources. Instead, they rely on data silos, creating further fragmentation. There are so many of these tools now that they confuse users, and many sites and partners cannot afford multiple solutions for similar or isolated tasks. It doesn't make financial, personnel, or operational sense.
Mature products are left to die by attrition, overshadowed by shiny new toys that boast one cool new feature, leading people to believe they do everything the mature solutions did. Meanwhile, the AI craze and walled gardens of proprietary products like Palantir take over, further complicating the landscape. In the C2 COP realm, mature solutions, with years of development and stability, are often disregarded for the allure of something new and shiny. We must shift our focus towards integration and modernization of these mature solutions, ensuring they evolve to meet current needs while maintaining the robustness and reliability they were built upon. Only then can we move away from the Island of Misfit Toys and towards a more cohesive and effective operational environment.
Standardization and Interoperability
And saying that we need to only focus on the data—that the tools don't matter — is part of the problem as well. The truth is they both matter holistically.
In the context and hype of Artificial Intelligence (AI) and Machine Learning (ML), something which every system now claims to incorporate in some way, I've heard from certain groups that we have to focus on data. That data is central to everything else.
This meme humorously shows the Department of Defense trying to leap directly to AI while skipping crucial steps like data governance, engineering, analytics, and science. Skipping these steps leads to unreliable AI because the data foundation becomes weak and fragmented. For warfighters, having the best data isn't enough, though. Tools need to be user-friendly, reliable, and designed to address specific workflows. AI models must be trained on relevant and up-to-date data. While data focus is critical, the tools built on it must also be robust and solve real-world problems effectively. A balanced approach considering both data and tools is essential for success.
I understand the point they are trying to make regarding data for AI/ML, but data in isolation does not solve all of our systems issues. What I believe they are trying to stress is the need for sources of truth like authoritative data sources — something I agree with. Systems can and should create their own data sources for their own bounded context, but they must have eventual consistency with the authoritative sources as well. The last thing we want are more data silos. But I have to ask myself how we continue to end up in the same mess when we have had authoritative data sources for decades. Yet, we also have numerous data silos brought about by shiny new tools. Or users claim that the authoritative data sources are outdated or not current. So why is that?
Well, the tools that read and write to those data sources are outdated and have not been updated or modernized in many cases. This has led users to still fight wars with Microsoft Office using Excel spreadsheets to maintain their world view or PowerPoint for briefing. There are several obvious problems here, but my point remains: we could have the best data and authoritative data sources in the world, but if we don't have easy-to-use tools that solve the warfighters' workflow needs, we will still have the same problems we have today. The visualizations are not just toys. They include middle-tier business logic, APIs, and visualizations that, hopefully, were designed with actual User-Centered Design practices that solve real-world issues.
This focus on data is where we were 20 years ago and led to some awful frontends and tooling. We again need a holistic picture of the problem. We need authoritative databases so that many tools can be created for our warfighters, solving their specific needs and still all having the same source of truth. But we also need to create these tools starting from the warfighter's problem they are trying to solve and work our way back to those data needs. It's both!
And yes, going back to AI/ML, we need good large sets of data—the model at the other end will only be as good as the data we fed it. This is typically where I start hearing about data standards. Why not just standardize the message formats or the database?
Consider over fifteen years ago when everyone believed XML would be the holy grail of message interoperability. XML is essentially a data format with a generic media type (e.g., application/xml) that has its pros and cons. Then came JSON, another data format that is similar but works better on the Web. However, both XML and JSON fail to convey context, protocol, or any inherent meaning. Out-of-band schemas can help describe the structure (e.g., syntax), but they still fall short in conveying the meaning (e.g., semantics) or possible actions (e.g., affordances). We should model actions, not just data.
Be conservative in what you do, be liberal in what you accept from others.
This is where content negotiation becomes crucial. Content negotiation allows a system to support multiple data formats and standards, making it more flexible and adaptable. By enabling the client and server to dynamically choose the best format for their communication, we ensure broader compatibility and interoperability. This is similar to how the Web functions: different browsers and servers can negotiate the best format (e.g., HTML, XML, JSON) to display the content correctly. By following Postel's Law — "Be conservative in what you do, be liberal in what you accept from others" — we create more robust APIs that can handle various data formats without enforcing a single standard.
In the context of REST architectural styles for communications and APIs, we use hypermedia-aware media types like HAL, SIREN, Atom, or Collections+JSON. These types use XML or JSON as a base format but add additional vocabularies, meaning, and affordances. This approach not only supports content negotiation but also adds the necessary context and actions to the data, making it more meaningful and usable.
Trying to mandate one data format is almost always a bad idea. A common misconception is that standards equate to interoperability. Standards and specifications do help, but implementations of the standards and specifications can vary widely in completion, version, proprietary extensions, errors, and ambiguities that lead to vendor differences. Another confusing aspect is what "standardized" actually means. I tend to think of standardization as a social thing. In other words, if everyone agrees that something means something, then it means something. This could just be a governance issue as well. I like this quote: "The nice thing about standards is that you have so many to choose from. Furthermore, if you do not like any of them, you can just wait for next year's model." - Tanenbaum. See the XKCD cartoon embodying this.
At some point, we have to face the music. I'm guessing by the framing of the original question that people believe there is some pot of gold at the end of the software architecture rainbow — a perfect design that abstracts away all of the details and intricacies of distributed systems and the inherent changes bound to occur in machine-to-machine communications — leaving all of DoD living happily ever after in a completely secure Mr. Clean-approved IC/DOD ecosystem. The problem here is that this goes against all historical evidence to date. Large-scale distributed systems do not behave in a precise, orderly, or predictable fashion. Whatever perfect approach one has in mind for surgically dealing with change will most likely miss the mark, deteriorate over time, and end up becoming technical debt. This tends to promote confusion and tunnel vision. Trying to live up to the "perfect" approach is like herding cats until you force someone to zen walk the earth along an exact line of latitude to see that the earth is indeed not flat.
I'm not proposing that hypermedia is a silver bullet — just that it seems to be the best solution I know of at the moment for distributed systems that need to evolve independently over time. I'm not saying we don't need standards either, just that we need to strike the right balance. Hint: academic data modeling, ontologies, and vocabularies that take five years to develop and begin integrating are not it!
Independent evolvability as an architectural property for distributed systems is my highest priority goal and is the reason I have always liked the REST/Hypermedia and microservices approach — your mileage may vary. In my opinion, we need to embrace inevitable change rather than trying to engineer our way out of it and take approaches that mitigate the barriers to and cost of dealing with it. To me, this means trade-offs, such as forgoing the short-term "convenience" of approaches like only focusing on the data. We need to focus on holistic solutions and the bigger picture. What is our vision? Then iteratively work our way to that, delivering value to warfighters along the way.
Funding, Collaboration, and Modernization
Funding and collaboration are crucial for successful modernization, but they often fall short due to misalignment with user needs. Joint Staff visits and well-intentioned user-centered design initiatives can sometimes miss what's really happening on the ground. For instance, I remember hearing that Site X loves the new tool "ShinyTool." When directly asked, a user at Site X stated they loved ShinyTool and used it daily. If I had stopped there, I would have left thinking this tool was exactly what they needed. However, after digging deeper and shadowing that user for days, I discovered they liked one specific feature of the tool and only used it for that. They didn't really use ShinyTool for its intended purpose; they just needed their current tools to perform that one feature better.
This kind of superficial feedback can lead to the death of mature solutions through funding attrition rather than well-thought-out modernization initiatives. Five years down the line, you end up with multiple tools, various non-authoritative local databases, and a fragmented system. I've learned through many failures in modernization initiatives how to properly modernize systems.
So why modernize at all? People want to modernize for several reasons: existing applications and architectures are often too broad, too large, and too slow. Remember when Agile meant speed, but we couldn't deploy fast enough. Then came DevOps, but getting infrastructure took too long. The cloud made infrastructure easier, but our systems weren't built for the cloud. Mission impacts arise as software changes ripple across all components, causing the all-or-nothing problem. Unsatisfied customers turn to other groups that engage and solve their needs quickly. Budgets shrink, and fiscal environments become tighter. Sometimes, modernization is exactly what is needed. Companies often focus too much on their customers' current needs and fail to adopt new technology or business models that will meet their customers' future needs. This short-sighted approach can lead to falling behind due to disruptive innovation.
Stakeholders face new challenges with AI/ML, cloud, mobile, various platforms, and persistent threats. These require a new way of thinking. Old application designs sometimes can't keep up, and massive monolithic applications break down under these new challenges. Forty percent of Fortune 100 companies from 2000 were no longer there in 2010. We need to constantly be innovating or die.
Successful companies can put too much emphasis on customers' current needs, and fail to adopt new technology or business models that will meet their customers' unstated or future needs. Such companies will eventually fall behind due to disruptive innovation.”
The typical evolutionary thought processes for modernization can miss important things about legacy systems. Systems typically grow up independently of each other. Over time, they become more interconnected and somewhat messy compared to modern solutions. People don't realize those connections are some of the most valuable pieces of the system but disregard that and try to design a new system that from the ground up does what the original system did, albeit with a more elegant solution.
System rebuilds through phased legacy replacement is a common modernization approach that often fails. It spends too much time trying to build everything over multiple years without delivering any value in between. Year one goes mostly well with installing new technologies, standardization, and rebuilding some basic functionality. By year two, we realize the oddities of the original system were there for a reason, leading to a mad rush to replace the legacy system. By years three to five, the project is often canceled. Large-scale refactoring is another common approach that fails. Refactoring in small steps can work, but for large legacy systems, it is not effective. Little changes here and there make it hard to keep the system working as we go along. It's challenging to change fundamental principles, making system rebuilds appealing. Dependency issues remain at the heart of the problem.
A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.
So what does this teach us? We learned that precision designs are fragile and often deny Gall's Law's original assumption that not all of a system will be well-designed. They provide no strategic value, just another version of what already exists, likely with less functionality. We also learned that independent evolvability is crucial for loose coupling and lasting architecture. We must realign with the user community to provide strategic value through small, focused, and vertical slices of working capability.
We need to build strategically valuable capabilities right away. Small autonomous services should work together to rapidly deliver capabilities while posturing for future disruptive IT—this is known as the Strangler pattern, which allows the existing system to be in use while slowly replacing it through new vertical slices of functionality that deliver value quickly.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
This isn't really a technical problem, either. Conway's Law states, "Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure." Choosing a particular architecture can optimize for a desired organizational structure, known as the Inverse Conway Maneuver. This means modernization efforts can't be solved by more money and focused efforts alone. We need to consider Conway's Law and its impacts. We need to learn from this and organize across the DoD more appropriately. These aren't just technical problems; they are organizational ones.
If we don't get this right and everyone haphazardly pulls at low-hanging fruit with a few shiny new features, we'll be in trouble. We don't have forever to get this right. The consequences of the "fight tonight" scenario are real. Timeframes like 2027 are too late for these shiny new tools. We will be fighting with our current mature toolsets that are languishing due to low funding and lack of focus.
Modernization is not just about adopting new tools or focusing solely on data. It's about a balanced approach that considers both data and tools, addresses real user needs, and builds on the robust foundations of existing systems. Only by doing so can we create an effective, resilient, and adaptable operational environment. By understanding and avoiding common pitfalls in modernization, keeping focused on the overall picture, funding things appropriately, and collaborating better, we can ensure our systems thrive. Software doesn't rust, but it does die if not maintained properly. We need to do a better job at software across the DoD.
Swag
One of the fun parts of attending the Joint C2 COP Working Group was the swag! The organizers handed out some neat Joint C2 COP Working Group pens and stickers, which made for nice little souvenirs. During a visit to the base exchange, I also picked up a stylish USSOUTHCOM polo that I can proudly wear. Unfortunately, I didn’t find any booster clubs with specific patches and coins, which I always love to collect. Still, I ended up with a good haul that commemorates this valuable experience.
South Florida Tourism
During our South Florida adventure, I had the pleasure of bringing my daughter along to explore the vibrant sights and flavors of Miami, Key Largo, and Fort Lauderdale. We kicked off our journey with a stay at the Marriott Biscayne Bay hotel in Miami, where we soaked in stunning views and enjoyed lazy afternoons by the pool. Despite the unpredictable weather, with frequent rain making national headlines, our time in South Florida turned into a cherished bonding experience amidst its unique charm.
Adding an extra thrill to our trip was the unexpected rental of a Dodge Challenger GT. Cruising around Miami in this souped-up car made us feel like characters out of a Miami Vice episode, perfectly blending with the city's energetic vibe. From the bustling streets of South Beach to the tranquil shores of Key Largo and the lively atmosphere of Fort Lauderdale's Las Olas Boulevard, each stop offered us new adventures and treasured memories. The mix of cultural richness, natural beauty, and culinary delights made our trip unforgettable, despite the weather challenges.
Let me tell you, though, the South Florida heat and humidity in June are no joke. The heat felt relentless, and the humidity was so thick it was like walking through a damp, warm blanket. Between the frequent rain showers and the sweltering temperatures, visiting South Florida in June is something I wouldn't recommend. Floridians must be built differently to handle this climate. It reminded me of winter in Philadelphia, where you just don't venture outside unless you have to—one is icy and snowy, and the other is just ungodly hot and sticky. But even with these weather extremes, our South Florida adventure was filled with moments of joy and exploration, making it a truly unique and memorable experience.
Miami
Our base for exploring South Florida was Miami, where we stayed at the Marriott Biscayne Bay hotel. On our first day, before the rain set in, my daughter and I soaked up the rays at Miami's iconic South Beach. The water was warm and clear, a stark contrast to the chilly, muddied waters of New Jersey and Delaware beaches back home—no need for the usual hesitant tiptoeing to get used to the temperature!
South Beach, known for its vibrant energy and stunning Art Deco architecture, is as much about the scene as it is about the sun and sand. We strolled along Ocean Drive, taking in the colorful buildings and lively atmosphere. The strip was bustling with life, and we couldn't resist indulging in some authentic Cuban food at one of the many local eateries. South Beach is very much a party beach—great if you're still in college, but not exactly ideal for a family outing. However, the energy was infectious, and we enjoyed every moment of it.
As the rains subsided on our last day, we visited the Vizcaya Museum and Gardens, which turned out to be my favorite experience of the trip. I have a special fondness for botanical gardens and historical places, particularly since the Philadelphia area is considered the botanical garden capital of the world. Vizcaya, a National Historic Landmark, was originally built as the winter residence of industrialist James Deering. The estate features stunning Italian Renaissance gardens, a sprawling mansion, and breathtaking views of Biscayne Bay.
Walking through the lush gardens and exploring the opulent rooms of the mansion, we felt transported back in time. The gardens were a serene escape, filled with vibrant flowers, intricate sculptures, and charming fountains. This visit was a delightful end to our Miami adventure, blending history, nature, and tranquility in a way that resonated deeply with us. The beauty and serenity of Vizcaya provided a perfect counterbalance to the lively, bustling energy of South Beach, making our Miami experience wonderfully diverse and memorable.
Key Largo
Our journey to Key Largo, about an hour's drive south into the Florida Keys, was an adventure in itself. The drive wasn't too bad, but let me tell you, Florida drivers do not understand the fast lane concept. They pick a lane and go slow! Almost as slow as Delaware drivers. Anyway, the ride was fun and went by quickly. By the time we arrived, we were hungry and found a lovely spot at Garden Cove Marina, enjoying a meal with a great view—complete with an alligator swimming in the water.
Our first stop was the Dagny Johnson Key Largo Hammock Botanical State Park. This park, named after a local environmentalist who worked tirelessly to protect the Florida Keys' natural habitats, offers a glimpse into the region's unique ecosystems. The park is home to one of the largest tracts of West Indian tropical hardwood hammock in the United States.
Our hike through the park, however, was short-lived due to the intense heat and humidity. As we ventured deeper into the hammock, we quickly encountered spiders the size of my hand and webs everywhere, accompanied by signs warning us to look out for gators. On top of that, we were getting eaten alive by mosquitoes. The combination had us running back to the car, laughing and scared out of our wits.
From there, we headed to John Pennekamp Coral Reef State Park, a renowned destination known for its vibrant coral reefs and marine life. The park features two shores: Far Beach and Cannon Beach. We walked around and admired the beautiful views of the water. While the park is famous for snorkeling, we didn't bring our bathing suits, so we stuck to exploring the trails and beaches. The park had some interesting characters that gave us a good laugh, adding to the day's fun.
After our adventures in Key Largo, we drove back to the hotel for some nighttime swimming in the pool and relaxing in the hot tub, ending our day on a perfect note.
Fort Lauderdale
Our adventures in Fort Lauderdale began with a special occasion. My daughter's friend from back home was visiting her family in Boca Raton, and since it was her birthday, we decided to meet up for dinner and fun in Fort Lauderdale—a perfect midpoint for both of us. This visit held a special meaning for me, as I was born in Fort Lauderdale but moved away when I was just six months old. This was my first time back, and it felt like a homecoming of sorts.
We started our evening with a delightful dinner, sharing stories and laughter. Afterward, we took a leisurely stroll along the famous Las Olas Boulevard. Las Olas, which means "The Waves" in Spanish, is known for its lively atmosphere, with a mix of shops, restaurants, and art galleries. It stretches from downtown Fort Lauderdale to the beach, offering a perfect blend of city and sea vibes.
As we walked, we soaked in the sights of the beach, enjoying the warm breeze and the sound of the waves. We treated ourselves to slushy piña coladas, which were refreshing and added a touch of tropical flavor to our evening. The vibrant energy of Las Olas was infectious, and we found ourselves immersed in the lively atmosphere.
To commemorate the trip, I bought my daughter a hoodie from one of the local shops—a keepsake to remember our fun-filled night. The blend of nostalgia, birthday celebrations, and the lively Las Olas scene made this a memorable part of our South Florida adventure.
After our time on Las Olas, we headed back to our hotel, reminiscing about the day's events and looking forward to the next part of our journey. Fort Lauderdale had welcomed us with open arms, leaving us with memories to cherish and a desire to return again someday.
Food
Exploring South Florida wasn't just about the sights and sounds—it was also a culinary adventure. Let me tell you, this area of the country is expensive. Food was not cheap! One place even charged us $10 for two small sodas. But the variety and quality of the food we experienced made it all worth it.
We started our mornings at Pura Vida, a trendy spot with multiple locations, including one in Edgewater near our hotel. My daughter, after some TikTok research, declared it a must-visit for healthy breakfasts and good coffee. We ended up getting some iced lattes here. The food looked great, but it was way too pricey for breakfast.
Our hotel, the Marriott Biscayne Bay, had an excellent restaurant called Gold Coast Kitchen + Cocktails. I typically enjoy Marriott restaurants, and this one didn't disappoint. I decided to try a Cubano sandwich, a classic Cuban sandwich made with ham, roasted pork, Swiss cheese, pickles, and mustard, pressed between Cuban bread. I wasn't sure about it at first, but when in Rome... It was absolutely delicious. My daughter mostly ate breakfast here and liked their lattes and mixed fruit cups.
In South Beach, we indulged in Cuban cuisine at Havana 1957 off Ocean Drive. This area is known for its great Cuban food, and this restaurant did not disappoint. I got the sampler to try a bit of everything. The only item I recognized were the empanadas, which were excellent. Everything else was a mystery but tasted great.
My daughter, however, wasn't a fan of Cuban food. So, despite my "When in Rome" philosophy, we ended up at Olive Garden for dinner two nights in a row. It was filling and consistent, but I'm slowly working on introducing her to more diverse cuisines. At least it was easier on the wallet!
In Key Largo, we dined at The Buzzard's Roost, where I had Mahi fish tacos blackened and served on flour tortillas with cabbage, pico de gallo, and a special house sauce. My daughter opted for a club sandwich. The food was great, but the view was even better. I only wish the weather wasn't so hot!
One afternoon, a coworker and I had lunch at La Tremenda Spanish Cuisine, not too far from USSOUTHCOM in Doral, FL. This small place in a strip mall exceeded my expectations. It was the best seafood paella I've ever eaten—absolutely recommend this place, and it was affordable too.
In Fort Lauderdale, we dined at Duffy's Sports Grill, which appeared to be a chain. They had a great strawberry daiquiri, but their wings weren't so great. Admittedly, I'm a bit of a wing snob, so others might enjoy this place more. This is also where we had dinner with my daughter's friend's family for her birthday.
In Miami, we visited the bustling Bayside Marketplace but decided to eat across the street at The Bagel Club Miami. My daughter and I loved the aesthetic, bagels, and coffee at this place!
Wrapping up our culinary journey, South Florida offered a mix of expensive yet delightful dining experiences. From trendy cafes to authentic Cuban eateries and scenic waterfront restaurants, each meal added a unique flavor to our adventure. Despite the high costs, the memories made over these meals were priceless, adding a delicious layer to our South Florida escapade.
Conclusion
In the complex and dynamic landscape of Command and Control (C2), it's imperative to remember that our systems, data, and tools are mere representations of reality, not reality itself. While these representations are invaluable for decision-making and situational awareness, they must be as accurate and common across tools as possible. The journey toward this goal requires a balanced approach, avoiding the allure of shiny new objects and the pitfalls of short-sighted hobby shop patches.
Modernization should be driven by a clear, end-goal vision, iteratively providing pieces of that vision through collaborative efforts. This means continuously refining our tools and data to better reflect the operational environment, ensuring that every update brings us closer to a seamless and integrated C2 system. By maintaining focus on this objective and securing the necessary funding, we can build a robust, adaptable, and effective operational framework that truly supports our warfighters.
Let's commit to a holistic and strategic approach, leveraging our collective expertise to create systems that not only represent reality but also enhance our ability to navigate and succeed in it. Only through sustained effort and collaboration can we achieve a common operational picture that meets the needs of today and anticipates the challenges of tomorrow.
See the associated LinkedIn post.
Comments
To leave feedback or questions, simply login using your preferred social network. I will read and answer your comments promptly, but please keep in mind that they will be public.